История изменений

Так, давай с базового уровня. Вот есть память приложений, память ядра, разделяемая память (которая используется сразу несколькими приложениями или драйверами в ядре), разные буферы и кеши. И то что свободно, её не следует занимать на 100% потому что механизмы «не хватает памяти, надо освободить» и «дай мне 100Мб» это совершено разные механизмы и выделение может рухнуть вместе с программой если нет запаса куда выделять.

swappines, mglur и всякие прочие планировщики и их настройки не указывают напрямую что вот столько надо держать в резерве (больше нет, хотя раньше да), но всё это как то влияет на решение что именно вытеснять в первую очередь, что во вторую, когда начинать и как активно действовать. Это ещё до того, как процесс упрётся в скорость процессора или диска.

Маленький swappines заставит отбрасывать кеши и максимально держать в памяти приложения, а большой наоборот, сбрасывать приложения но держать в памяти большой кусок кешей. Сейчас выбор совсем не очевиден! Приложения написаны так, что в них дофига мёртвого кода, часто можно сбросить в своп 50-70% и это никак не скажется на реальном функционале и скорости приложения. С другой стороны то что вроде бы ненужный кеш может оказаться кодом библиотеки или базы данных, к которой надо обращаться тысячи раз в секунду. В итоге средние значения swappines от 50 до 150 при быстром ssd работают примерно одинаково, а разницу надо искать в структуре чтения и записи на диск. Классикой считается 100 или 150, ходят упорные слухи что это лучше чем 60.

Дальше, когда принято решение вытеснить страницы - встаёт вопрос куда именно. Если активирован zswap - сначала туда. Страница будет сжата и помещена в zpool. Если страница не сжимаемая или пул переполнен - она разжимается и отправляется в своп.

Своп состоит из нескольких устройств с разными приоритетами Сначала заполняются до отказа те, у которых приоритет выше. Если одинаковый -делится поровну между ними.

И вот тут появляется zswap - он может быть одним из этих устройств. Всё что в него отправлено будет сжато и как положили так и будет лежать (за исключением backing_dev, но это позже). Сначала до отказа забивается zswap и продолжает висеть в оперативке, заняв там некий кусок (как получится, возможно даже 100% от разжатого объёма). Всё что сверху будет отправлено в менее приорететное устройство (физический диск очевидно) без сжатия. В сценарии когда ты открываешь вкладки в браузере бесконечно большими пачками - после заполнения zswap тебе придётся жить без него в оставшейся оперативке пока ты не вернёшься к самым первым вкладкам.

И вот чтобы этого избежать, придумали backing_dev. По сути свой собственный своп для zswap. Работает как своп, только исключительно для содержимого zswap. Позволяет включить себе бесконечно большой zswap, хоть в 1000 раз превышающий оперативку и он не переполнит ОЗУ. Можно указать какой именно объём zswap будет физически занимать в оперативке.

Очевидно одновременное включение zswap и zram - тупая идея. Надо выбрать, или тот или другой с backing_dev. Или без backing_dev, но это предварительно подумав почему именно тебе именно в этом сценарии ужно так сделать. zswap с околодефолтными настройками даст тебе 90% всех возможных плюшек. Нормально настроенный zram+backing_dev даст 100%. Но если так подумать, то за счёт голой производительности современных ssd и быстрых шин ты получаешь 50-70% от этого вообще не используя сжатие свопа. Вот на hdd или usb2-ssd свопинг действительно превращается в тормоза...

Так, давай с базового уровня. Вот есть память приложений, память ядра, разделяемая память (которая используется сразу несколькими приложениями или драйверами в ядре), разные буферы и кеши. И то что свободно, её не следует занимать на 100% потому что механизмы «не хватает памяти, надо освободить» и «дай мне 100Мб» это совершено разные механизмы и выделение может рухнуть вместе с программой если нет запаса куда выделять.

swappines, mglur и всякие прочие планировщики и их настройки не указывают напрямую что вот столько надо держать в резерве (больше нет, хотя раньше да), но всё это как то влияет на решение что именно вытеснять в первую очередь, что во вторую, когда начинать и как активно действовать. Это ещё до того, как процесс упрётся в скорость процессора или диска.

Маленький swappines заставит отбрасывать кеши и максимально держать в памяти приложения, а большой наоборот, сбрасывать приложения но держать в памяти большой кусок кешей. Сейчас выбор совсем не очевиден! Приложения написаны так, что в них дофига мёртвого кода, часто можно сбросить в своп 50-70% и это никак не скажется на реальном функционале и скорости приложения. С другой стороны то что вроде бы ненужный кеш может оказаться кодом библиотеки или базы данных, к которой надо обращаться тысячи раз в секунду. В итоге средние значения swappines от 50 до 150 при быстром ssd работают примерно одинаково, а разницу надо искать в структуре чтения и записи на диск. Классикой считается 100 или 150, ходят упорные слухи что это лучше чем 60.

Дальше, когда принято решение вытеснить страницы - встаёт вопрос куда именно. Если активирован zswap - сначала туда. Страница будет сжата и помещена в zpool. Если страница не сжимаемая или пул переполнен - она разжимается и отправляется в своп.

Своп состоит из нескольких устройств с разными приоритетами Сначала заполняются до отказа те, у которых приоритет выше. Если одинаковый -делится поровну между ними.

И вот тут появляется zswap - он может быть одним из этих устройств. Всё что в него отправлено будет сжато и как положили так и будет лежать (за исключением backing_dev, но это позже). Сначала до отказа забивается zswap и продолжает висеть в оперативке, заняв там некий кусок (как получится, возможно даже 100% от разжатого объёма). Всё что сверху будет отправлено в менее приорететное устройство (физический диск очевидно) без сжатия. В сценарии когда ты открываешь вкладки в браузере бесконечно большими пачками - после заполнения zswap тебе придётся жить без него в оставшейся оперативке пока ты не вернёшься к самым первым вкладкам.

И вот чтобы этого избежать, придумали backing_dev. По сути свой собственный своп для zswap. Работает как своп, только исключительно для содержимого zswap. Позволяет включить себе бесконечно большой zswap, хоть в 1000 раз превышающий оперативку и он не переполнит ОЗУ. Можно указать какой именно объём zswap будет физически занимать в оперативке.

Очевидно одновременное включение zswap и zram - тупая идея. Надо выбрать, или тот или другой с backing_dev. Или без backing_dev, но это предварительно подумав почему именно тебе именно в этом сценарии ужно так сделать. zswap с околодефолтными настройками даст тебе 90% всех возможных плюшек. Нормально настроенный zswap+backing_dev даст 100%. Но если так подумать, то за счёт голой производительности современных ssd и быстрых шин ты получаешь 50-70% от этого вообще не используя сжатие свопа. Вот на hdd или usb2-ssd свопинг действительно превращается в тормоза...