zram — lz4, lzo или zstd?

Использую zstd, так как где то нагуглил тесты и zstd оказалась лучшей в многопотоке для zram.

NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd         31.4G   4K   66B    4K       8 [SWAP]

Пока там пусто – не так интересно, сам понимаешь. Ну и с таким размером памяти не так просто начать заполнять своп, конечно.

Кстати, рекомендуют делать число свопов по числу ядер (кроме потоков внутри каждого) — ядро с ними работает как c raid0, типа того.

Уже нет, смотри streams. Раньше zram был однопоточный, и действительно было нужно заводить по одному свапу на ядро. Сейчас не нужно, его научили и в многопоток, и в вытеснение сжатых страниц в физический свап при переполнении виртуального.

Вот такие соображения есть на счёт нескольких zram устройств:

Как бы еще ускорить систему? (комментарий)

Тестировал, ощутимой разницы в скорости нет, мудрить тут уже нет никакого смысла. Это было актуально при работе с несколькими медленными устройствами на разных шинах. А у нас всё в памяти происходит и лимитирует компрессия, а не пропускная способность устройства или его интерфейса.

Видимо, так и есть. Все эти «разные» zram устройства всё равно работают через тот же самый CPU. Встречал упоминания, что такое может иметь смысл в случае NUMA архитектуры.

https://askubuntu.com/questions/1171950/why-is-ubuntu-configuring-multiple-zram-devices-for-swap

У меня NUMA кстати. Две головы по четыре «честных» ядра в каждой, без гипертреда, на каждой своя память. Ядро при выборе «правильного» шедулера и включённой поддержке NUMA само прекрасно разбирается как память распределить и потоки раскидать. Сначала тоже мудрил с numactl и ручным раскидыванием памяти и потоков по нодам, пока не убедился что в этом нет никакого смысла. Правда у меня самосборное ядро и выбран подходящий под мою архитектуру и процы шедулер, учитывающий особенности NUMA.