zram и zswap или что то ещё,вместе?

емнип, zram научился в многопоток, теперь можно спокойно выделять один жирный сегмент

несколько zram разных алгоритмов и приоритетов можно еще

zram и zswap можно использовать вместе, есть ли распределение, приоритеты?

Насколько знаю, zswap нельзя использовать только на конкретное устройство, значит вместе zram и zswap использовать не стоит.

зачем

Не рекомендую использовать zram, если есть вероятность уйти в своп. Её наличие в этом случае только усугубляет проблему.

zswap нельзя использовать только на конкретное устройство

Что означает эта фраза?

На самом деле при совместном использование будет просто лишняя нагрузка на ЦП - страницы попадают в пул zswap в сжатом виде, при попытке выгрузки на устройство разжимаются, а если этим устройством является zram - снова сжимаются.

lz4 lzo, и что то новенькое появилось?

Начиная с Linux 5.1 дефолт lzo-rle. Хороший дефолт. zstd - альтернатива - сжимает сильнее, но, возможно, медленнее.

стоит ли ставить на несколько ядер маленькими кусочками

Одного устройства достаточно - сейчас устройства zram многопоточны.

Если у тебя HDD - сжатие мастхэв.

zram позволяет избежать своппинга на медленный диск.

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

Не рекомендую использовать zram, если есть вероятность уйти в своп

Наоборот, при неизбежности своппинга zram - лучшее решение.

Например:

https://youtu.be/PLVWgNrVNlc – opening multiple chromium tabs with 2.3 GiB memory and 1.8 GiB swap space on zram.

https://youtu.be/d4Sc80TMEtA - webkit2gtk3 compilation with zram-fraction=1, max-zram-size=8192. No hangs, no heavily freezes, system was responsive for all time during webkit2gtk3 compilation.

https://youtu.be/c5bAOJkX_uc - playing supertuxkart with 7 threads while true; do tail /dev/zero; done in background.

Все демо со zram - гуй жив, работать можно, даже под стрессами.

Ко всему прочему установи vm.watermark_scale_factor=100 и используй earlyoom или nohang-desktop.

Здесь нет свопа на диск, всё умещается в zram. Будет два своп-файла - узнаешь про LRU inversion и его друзей.

Зачем мне 2 своп-файла? Достаточно одного zram-раздела.

Ты всерьёз говоришь человеку со 100 Гб свопа, что он не нужен?

узнаешь про LRU inversion и его друзей.

Как оно проявляется и что это?

Ты всерьёз говоришь человеку со 100 Гб свопа, что он не нужен?

Сколько ОЗУ? Какие задачи?

При наличии двух своп-разделов - на zram и на диске - обычно выставляют высокий приоритет для zram.

В своп сначала вытесняются самые старые inactive anon pages, и всё - zram выбывает из игры. При этом zram устройство использует часть памяти, но при этом фактически не используется.

zswap лишен недостатка.

Проблема касается zram при совместном использовании свопа на zram и на диске с разными приоритетами.

24, Java, Android, рендер, разного рода компиляния.

Насколько заполнен своп под нагрузками? Жив ли гуй при этом?

Пока у меня на ноуте было «всего» 16 гиг оперативы, я юзал вот такой скрипт, который сетапил zswap c быстрым алгоритмом компрессии lz4 (средний коэффициент сжатия ~2) и zram с zstd (самый быстрый из эффективных алгоритмов, средний коэффициент сжатия ~3). При этом бывший своп файл использовался для сброса плохо сжимаемых страниц после zram. Никаких проблем не наблюдал

swapoff /swapfile
  
echo lz4 > /sys/module/zswap/parameters/compressor
echo z3fold > /sys/module/zswap/parameters/zpool
echo Y > /sys/module/zswap/parameters/enabled

modprobe zram
losetup -f /swapfile
echo $(losetup | grep swapfile | awk '{print $1}') > /sys/block/zram0/backing_dev
echo zstd > /sys/block/zram0/comp_algorithm
echo 0 > /sys/block/zram0/mem_limit
echo 4G > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

Linux съел мою память!

UI полностью работоспособен, когда используется ограниченный набор из запущенного софта, способный вместиться в RAM, и жутко лагает, если разворачивать окна давно ушедших в своп или в принципе не помещающихся в RAM программ.

При использовании zswap и zram, страницы в zram будут выгружаться в сжатом виде из zswap, zram ничего не сможет сжать повторно. Причём выгружаться будут массово, большими страницами на сотни мегабайт. Способа использовать zswap для конкретного zswap-устройства я не нашел (способа отключить использование zswap для zram-устройства).

Исходники не смотрел, но использовал zram и zswap одновременно какое-то время, и всё работало крайне печально. Проведите тест самостоятельно.

Zswap абсолютно точно разжимает страницы при выгрузке в swap устройство, потому как кроме zswap никто не в курсе, что страницы сжаты.

Может у Вас стояли алгоритмы сжатия медленные или были изменены дефолтные настройки swappiness или watermark_scale_factor?

У меня zramctl при включённом zswap всегда показывал примерно равные значения data и compr, т.е. данные в zram попадали несжимаемые (уже сжатые). Как только я отключил zswap, zramctl начал отображать нормальные цифры (compr сильно меньше data). Именно об этом я говорю — способа ограничить работу zswap только для конкретных swap-устройств, похоже, нет, и исключить его из zram нельзя.

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

Тогда Вы видели обычное поведение zswap’а. Страницы которые не сжимаются он отправляет в swap сразу, если в качестве swap’а был zram, то он, что логично не мог их сжать. Сейчас в zram можно указать устройство куда он будет сгружать несжимаемые страницы, чтобы они не висели в памяти мёртвым грузом

У zswap два основных способа хранения страниц. В одном он хранит объёме одной страницы максимум две сжатых (в среднем сжатие 1.7 даже для хороших алгоритмов сжатия), во втором – 3, что даёт сжатие 2+ даже для lz4. Так что он может сбрасывать страницы в своп устройство по 2-3 штуки

Что касается массовых выгрузок, то мне кажется, это как раз был случай с большим количеством плохо сжимаемых страниц памяти, которые zswap сразу же отдавал в zram, вот и было похоже, что он массово сбрасывает сжатые страницы

А просто вызвать zramctl не вариант?

Вариант, но тут есть два нюанса.

1. В zram нельзя выбрать два алгоритма сжатия – типа сожми через lz4 сразу, а потом через zstd когда будет не занят проц

2. zram не умеет отдавать оперативку (во всяком случае не умел, когда я его тестил в прошлый раз)

У zswap тоже нельзя использовать два алгоритма сжатия, но он отдаёт оперативку, ценой максимальной степени сжатия 3 (не может хранить более трёх сжатых страниц на месте одной).

Соответственно связка из zswap + zram позволяет использовать два алгоритма сжатия и при этом выделить на zram небольшой кусок оперативки, изьятие которого из общего пула не скажется на производительности. Единственный минус такой связки – бОльшая нагрузка на процессор, что в было бы проблемой лет 5 назад, но сейчас даже интеловские атомы показывают неплохие результаты.

Тогда Вы видели обычное поведение zswap’а. Страницы которые не сжимаются он отправляет в swap сразу, если в качестве swap’а был zram, то он, что логично не мог их сжать.

Зачем, в таком случае, вообще использовать zram вместе с zswap? zswap отправляет несжимаемые страницы в zram, и zram их тоже не может сжать. Причем zswap, когда больше их не использует, делает reclaim только виртуально (забывает о страницах), но (по ощущениям, код не смотрел) не информирует нижестоящее устройство (zram в вашем случае) об их неиспользовании, из-за чего zram их продолжает хранить.

zram не умеет отдавать оперативку (во всяком случае не умел, когда я его тестил в прошлый раз)

Вы тестировали вашу связку zram+zswap? Это она «не умеет отдавать оперативку».

из-за чего zram их продолжает хранить.

Ну тогда и своп файл/раздел хранили бы их, а значит забивались бы и своп бы кончился после нескольких запусков-закрытий больших приложений

Я не про весь скрипт, а про второй его кусок.

backing_dev можно назначить после создания zram-устройства, точно зная его название.

Вместо грепанья вывода можно добавить параметр --show, чтобы программа losetup напечатала имя назначенного loop-устройства.

Это стандартное поведение zram с момента его появления. Он не занимает оперативку при создании, но как только страницы памяти заняты данными, он не отдаст системе оперативку обратно, даже если в swap нет данных. Для top подобных утилит этого не видно, но видно по занятим страницам в /proc/meminfo например

А, Вы в этом смысле. Да, так, конечно можно. Вопрос привычки

Будет два своп-файла - узнаешь про LRU inversion

However, zsmalloc does not implement compressed page eviction, so once zswap fills it cannot evict the oldest page, it can only reject new pages.

Таким образом, zswap с zsmalloc также подвержен LRU inversion.

https://www.kernel.org/doc/html/latest/vm/zswap.html

здорово, правда?

Всё верно, но есть нюанс).

zsmalloc не используется по умолчанию уже очень давно. Вместо него по умолчанию обычно zbud, который отдаёт память. Плюс добавили z3fold, который как zbud, но хранит не «максимум 2 страницы в одной», а «максимум 3 страницы в одной».

Ну тогда и своп файл/раздел хранили бы их, а значит забивались бы и своп бы кончился после нескольких запусков-закрытий больших приложений

1. Вы запускаете программу, которая использует очень много памяти в процессе работы, из-за чего на каком-то этапе в swap попало 500 МБ anon-страниц этой программы.

2. Вы закрываете программу. 500 МБ из swap «пропадают», zswap о них забывает, но данные остаются в swap (они физически не зануляются.).

3. На реальном HDD или SSD это не проблема, но zram продолжает бережно хранить эти 500 МБ в оперативной памяти и не знает, что они уже отброшены.

Вот так, по моим ощущениям, работает zswap — он не даёт знать zram о том, что страницы нужно reclaim’ить.

Иными словами, я подозреваю, что zram-устройство не поддерживает trim/discard.

zsmalloc не используется по умолчанию уже очень давно

Никогда и не использовался. zbud давно по умолчанию, с древних времен.

Кстати, отведайте новый патч https://github.com/hakavlad/le9-patch/blob/main/le9ca_patches/le9ca2-5.10.patch

Защищает только чистые страницы и фиксит 12309 при любом размере dirty - киллер приходит до сброса всех грязных.

Угу). Тогда я не понимаю посыла Вашего предыдущего комментария. То что zswap позволяет «выстрелить себе в ногу», если сильно постараться? Ну да, есть такое)

Вообще, я некоторое время игрался с zram/zswap/lvm cache/preload и ещё несколькими штуками, пытающимися улучшить работу компьютера, используя некоторые предположения о сценарии его работы, и пришёл к малоутешительному выводу - если бы любая из этих штук действительно давала выигрыш без серьёзных побочных эффектов, она давно была бы включена в десктопных дистрибутивах по дефолту. На андроиде оно прокатывает за счёт ограничений, накладываемых ОС на пользовательские таски, в общем же случае зачастую больше вредит.

Мой посыл — zram и zswap несовместим в текущем виде. Так как zswap нельзя включить для конкретного (реального) swap-устройства, а можно включить только глобально (в т.ч. для zram), использовать zram и zswap одновременно не стоит — это только создаст проблем.

«zram и zswap стреляют в ногу именно в той ситуации, которую должны разрешать, если она хуже, чем им хотелось бы».

Хм, ну это наблюдение подтверждает тезис о том, что zram не умеет отдавать оперативку. Хм, с другой стороны я никогда не монитровал swap раздел на zram с параметром discard. Можно попробовать, хоть я и сомневаюсь, что zram этому научили.

В Windows 10 есть сжатие памяти, и в целом работа с памятью сделана значительно лучше, чем в Linux. Компьютерами с 1 GB RAM можно пользоваться с Windows 10, но не с Linux. Разработчики Chrome OS, между прочим, знают о проблеме и её причинах, и она более-менее устранена в форке ядра для Chrome OS (и zram там тоже включён уже чуть ли не 10 лет как).

zram-устройство не поддерживает trim/discard

Разумеется, ведь Trim входит в спецификацию интерфейса ATA. zram - вируальное устройство, не использующее ATA.

Однако отсутствие Trim не имеет отношения к инверсии LRU.

zram без zswap проблеме не подвержен.

Да, видел. По ощущениям, за последние 10 лет обе ОС сильно улучшили эффективность использования свопа, но винда в этом продвинулась дальше.

если бы любая из этих штук действительно давала выигрыш без серьёзных побочных эффектов, она давно была бы включена в десктопных дистрибутивах по дефолту

Это ложь. Есть куча штук, которые можно включить по дефолту и которые работают.

Пример - zram и earlyoom в Федоре. И убунта. поторая до сих пор не включила ни то, ни другое.

И патч, резервирующий файловые страницы - патч известен и работает, но дистроделам он не интересен.

да, да, теории заговора, плавали, знаем.

Хм, ну это наблюдение подтверждает тезис о том, что zram не умеет отдавать оперативку.

Не ломайте zram, и все будет отдано. Используйте своп только на zram - и проблемы не будет.