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

Конечно, страница будет распакована в ram.

Ещё вопрос, а можно принудительно запихнуть страницу в zram по адресу?

Вы говорите, что с версии 7.0 страницы третьего типа тоже могут перемещаться в disk swap. Вопрос, алгоритм вытеснения страниц третьего типа оперирует с ними как будто они обычные страницы рам, или там всё сложнее и используется анализ их содержимого и частоты доступа?

Это я про zram говорил, раньше перед вытеснением страницы в физический своп, zram ее предварительно распаковывал. И в нем нет никаких алгоритмов для выбора приоритетных страниц, в отличии от zswap. А как конкретно это все работает я не знаю.

Я понял. Спасибо!

У меня zram показывает размер блока 4096. Исходя из каких расчётов он таким получился не знаю, но очевидно это совпадает и с размером x86 страницы памяти и с ещё много какими размерами в разных аспектах хранилищ.

Про unified shared memory не особо знаю, но по-моему к свапу прямого доступа у устройств быть не может. Или может быть такое, что видеокарта отправляет запрос «хочу такой-то блок», линукс это видит, распаковывает блок из zram в несжатое представление и отдаёт его видеокарте? Сомневаюсь.

Если что, создать zram очень просто:

modprobe zram num_devices=3

появятся /dev/zram0 zram1 zram2 и их конфиги в /sys/block/zram0 zram1 zram2

В конфигах нужно настроить disksize - размер в байтах (1000000 округлилось до 1003520, кратного 4096) и можно настроить ещё что-то.

А можно провести аналогию что физический своп это гараж за несколько км, а зрам - шкаф. Наверно от выгрузки крайне ненужных данных в гараж есть смысл, но если вещей не много, то не очень.

Отлично, я думаю, что разобраться можно. Всем огромное спасибо. Закончатся все эти пляски с OpenCL и Sycl, народ накатается, вернётся, напрягу. Пусть лучше делом займутся, чем всякой фигнёй с этими сиклами-шмиклами страдать.

Ну вот, а тут жаловались, что ресурс только для потрещать! Кому-то и потрещать, как вон в обсуждении про очередной апдейт от Столерова, а кто-то и дело делает! Спасибо всем!

Везде написано отключать zswap, потому что с ним страница сначала сжимается в его кэш, потом распаковывается для записи в swap, и так как swap на zram, то сжимается опять, то есть получается бессмысленная двойная нагрузка на cpu. А обычный swap прекрасно работает с zram

Кстати отключать zswap надо через параметры загрузки ядра, через sysctl не отключается.

По поводу writeback, он работает не автоматически, а вручную echo $cmd > /sys/block/zram0/writeback где $cmd huge - несжимаемые, idle - простаивающие, huge_idle или all. Простаивающие 600 секунд помечаются через echo 600 > /sys/block/zram0/idle, нужно каждый раз перед writeback помечать.

Но ведь своп тем более на ссд это точно не гараж.

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

написано отключать zswap

что если свапа нет вообше - он все равно включен? и если включен с чем тогда взаимодействует?

надо уметь готовить

да все уже сготовлено по максималке - под зрам выделена вся рам, yoom установлен - если что вырубает все.

зрам своп отключать нужно

нафейхоа?! Ну в смысле можно и отключать, но только с backing_dev. Но будь у тебя оно - то что ты описал не могло произойти.

https://docs.kernel.org/admin-guide/blockdev/zram.html

Опции:

echo lz4 >  /sys/block/zram0/comp_algorithm
echo 2G > /sys/block/zram0/mem_limit
echo /dev/sdb1 >  /sys/block/zram0/backing_dev
echo 30G > /sys/block/zram0/disksize

Теоретически вот так должно получиться 30 гектар свопа, 2Гб сжатых данных из которых расположится в оперативке а остальное упадёт на backing_dev.

На практике... дебиан 11, ядро 4.19, вместо свопа я создал там ext4 и начал накидывать мусор из /usr и /opt. Как только zram добирается до mem_limit - ошибка i/o, устройство вываливается в ro (что кстати в первый раз произошло на отметке 18Гб при лимите 2Гб). На чём то более свежем проверить не могу, в распбиане у меня ядро собрано без backing_dev. Возможно это недостаток старого ядра, возможно та и было задумано, документацию можно трактовать так, как будто backing_dev проглатывает исключитеьно несжимаемые страницы.

В любом случае, даже если с backing_dev такая шляпа, всегда можно испольовать голый zram + физический своп. Тогда система не встанет колом а продолжит свопиться, просто без плюшек сжатия памяти. Я так на Пи3 дофига лет жил, а проблему забивания zram мёртвыми данными лечил создав 2 устройства zram и хроном каждый час попеременно высвобождал и снова подключал одно из них. Работало! Да, конечно zswap делает это полностью прозрачно, из коробки и с микроскопическими недостатками, но и с zram можно жить весьма неплохо и без лимитов памяти в пределах объёма диска.

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

И арчвики и альтвики на эту тему весьма скудно, причём я не заметил чтобы было объяснено зачем.

дежурная флеха с установленым альтом и свопа на ней нет, вместо свопа - зрам

С этого и надо было начинать! Доволньо оригинальная конфигурация, действительно имеет смысл без свопа, на флешку свопиться это просто АДЪ. Но в типовых то сценариях, даже с hdd, даже с очень медленным, физический своп нужно добавить.

Собственная память zram не является ни anonymous memory, ни page cache — не может быть вытеснена в swap.

Вероятно это память ядра. Но значительная часть памяти ядра - вытесняемая. Там наверное действительно надо читать исходники.

чтобы что-то сбросилось на backing_dev надо выполнять команду echo huge (или all) > /sys/block/zram0/writeback

Ещё один очень важный вопрос, а что, если я использую Unified shared memory и хочу иметь доступ к данным в zram из других устройств на PCIe шине, скажем из графического процессора или сетевой карты?

Очевидно видеокарта дёрнет ядро линукса, ядро поймёт что страницу надо предоставить и дёрнет её из свопа. Или эта Unified shared memory реализована в виде dma-буферов и вообще не видится как доступная приложениям?

Можно подробнее? Док ядра на эту тему непонятный, а бегать гуглить не интересно, я всё равно за использование zswap.

Арчвики:

If the related zswap kernel feature remains enabled, it will prevent zram from being used effectively. This is because zswap functions as a swap cache in front of zram, intercepting and compressing evicted memory pages before they can reach zram. Despite the output of zramctl(8), most of zswap is unused in this circumstance. Therefore, it’s recommended to permanently disable zswap using the kernel parameter or sysfs setting before starting.

Мы о другом. Он утверждает что отключать надо не zswap а физический своп.

Всё, увидел. Кажется с all получится полный аналог zswap и даже с небольшим бонусом скорости.

Ну этот вопрос действительно слоба на арчвики:

Incompressible pages can then be pushed to the block device by executing:

echo huge > /sys/block/zramX/writeback

Я как раз по https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#optional-feature разбирался, причем там тоже как-то кратко, так что пришлось экспериментировать. Поначалу я подумал что надо один раз настроить и оно дальше само, но оказалось что каждый раз надо и idle помечать и в backing_dev отправлять. Поэтому сделал systemd.timer

$ systemctl --no-pager cat zram-idle.timer zram-idle.service
# /etc/systemd/system/zram-idle.timer
[Unit]
Description=Run zram0 idle/writeback setup every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=1s
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/zram-idle.service
[Unit]
Description=Set zram0 idle and writeback parameters

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo 600 > /sys/block/zram0/idle && echo huge_idle > /sys/block/zram0/writeback && cat /sys/block/zram0/bd_stat'

Рабоает так:

$ journalctl _TRANSPORT=stdout -u zram-idle.service --since "2 hour ago" -f
мая 09 20:45:00 station bash[73903]:    27864    12038    40473
мая 09 20:50:00 station bash[77733]:    27848    12054    40473
мая 09 20:55:00 station bash[79543]:    27900    12064    40535
мая 09 21:00:00 station bash[81669]:    27901    12064    40536
мая 09 21:05:00 station bash[84659]:    27909    12064    40544
мая 09 21:10:00 station bash[87352]:    27956    12065    40592
мая 09 21:15:00 station bash[89334]:    28579    12068    41218
мая 09 21:20:00 station bash[92031]:     4207    12278    41408
мая 09 21:25:00 station bash[93917]:     4198    12287    41408
мая 09 21:30:00 station bash[95701]:     4198    12287    41408
мая 09 21:35:00 station bash[97692]:     4149    12289    41409
мая 09 21:40:00 station bash[99437]:     4080    12381    41432
мая 09 21:45:00 station bash[100719]:     4080    12382    41433
мая 09 21:50:00 station bash[102073]:     4076    12386    41433
мая 09 21:55:00 station bash[103436]:     4076    12386    41433
мая 09 22:00:00 station bash[104853]:     4076    12386    41433
мая 09 22:05:00 station bash[106236]:     4076    12386    41433
мая 09 22:10:00 station bash[107639]:     4076    12386    41433
мая 09 22:15:00 station bash[108932]:     4076    12386    41433
мая 09 22:20:00 station bash[110272]:     4075    12387    41433
мая 09 22:25:00 station bash[112084]:     3916    12546    41433
мая 09 22:30:00 station bash[113551]:     3916    12546    41433
мая 09 22:35:00 station bash[115305]:     3916    12546    41433
мая 09 22:40:00 station bash[117222]:     3910    12551    41433
мая 09 22:45:00 station bash[119007]:     3913    12551    41436

Это 4к блоки, сейчас хранится, всего было считано, всего было записано, т.е. всего несжимаемых простаивающих блоков было записано 160Мб, а в данный момент их там хранится 15Мб

Ещё раз, я правильно понял что echo 600 > /sys/block/zram0/idle это не «считать простаивающими всё что старше 600с и отправлять в backing_dev», это однократно пометить, чтобы сбросить следующей командой? И всё это надо каким нибудь хроном или системд гонять каждые n секунд? Т.е. при высокой скорости свопинга остаётся шанс положить систему уткнувшить в mem_limit?

физический своп нужно добавить

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

Когда я первый раз прочитал про zram, подумал, что это какой-то прикол. Разве можно выиграть существенный объём? Зато производительность явно просядет.

Не совсем, это просто однократная установка флага idle, посмотеть помеченные блоки можно /sys/kernel/debug/zram/zram0/block_state (https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#memory-tracking) Имеет смысл только для idle и huge_idle, несжимаемые huge или all можно и так скидывать.

По поводу высокой скорости своппинга, скорее всего будет чуть получше чем при обычном свапе и даже zswap, потому что на backing_dev можно скидывать сжатые блоки (по умолчанию в zram-generator, или включать echo yes > /sys/block/zramX/compressed_writeback)

mem_limit тут никаким боком, это просто верхняя граница использования ram под zram, похоже все его путают с disksize. При его достижении думаю будет OOM, последнее приложение прибьётся.

Минусы выставления большого zram и маленького swappiness? (комментарий) вот тут я внезапно для себя уткнулся в крах zram при достижении mem_limit. Потом как нибудь прогоню с настройками huge_idle и compressed_writeback.

Попробовал сделать zram 4G > disksize, 256M > mem_limit, yes > compressed_writeback и backing_dev размером 1G, смонтировал и начал копировать по 500M. На bd влезло только 1G, так что похоже запись зжатых блоков не работает. Всего до ro влезло 1,6G

# zramctl --output-all
NAME       DISKSIZE  DATA  COMPR ALGORITHM STREAMS ZERO-PAGES TOTAL MEM-LIMIT MEM-USED MIGRATED COMP-RATIO MOUNTPOINT
/dev/zram1       4G  1,6G 250,1M zstd                    1032  256M      256M     256M       0B     6,4615 /tmp/zram1
# cat /sys/block/zram1/bd_stat 
  261550     2373   262166

Но ro получается думаю из-за монтирования файловой системой, в случае swap скорее всего просто OOM будет при достижении mem_limit.

Выше про all наврал, all надо в idle писать, а не в writeback.

Вообще, zram тупое блочное устройство, zswap намного умнее должен быть, но лично мне (с нехваткой пары гигабайт ram) zswap на sata ssd не помог, а zram справился.

Но ro получается думаю из-за монтирования файловой системой, в случае swap скорее всего просто OOM будет при достижении mem_limit.

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

Сегодня тестировал работу zram и zswap. Ноутбук, nvme, 8Гб озу, частота цпу 800мгц фиксированно.

Открыто два браузера в каждом по 28 вкладок. Плюс набор десктоп приложений. Алгоритм сжатий одинаковый: zstd. Условия тестирования одинаковые.

Итоги: с zram фризит так, что курсор замирает на минуту две. С zswap работает без фризов.

ZRAM всё держит в блочном устройстве. ZSWAP держит в сжатом кеше только горячие данные, которые используются прямо сейчас, остальное вылетело на обычный свап.

Всего использовалось 12Гб оперативной памяти (озу+swap), на zram фризы, работать не возможно. На zswap работает всё отлично. C vm.swappiness = 60, какая бы не была нагрузка, доступными всегда остаётся 900мб озу. Если выставить 200, то всегда будет доступно 2Гб, что для меня излишне.

Для себя окончательно выбрал zswap.

частота цпу 800мгц фиксированно.

фризит

частота цпу 800мгц фиксированно.

фризит

С zswap нет. С zram да. Cжатые данные в кеше zswap были около 900 мегабайт.

Современные ядра на 800 это может быть весьма жирно и точно мощнее чем коре2 на 3Ггц.

С zram да.

Ну так, как минимум, использовать алгоритм сжатия полегче, а не zstd. Раз уж настолько задушил процессор. На выбор, lzo-rle или lz4.

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

Чтобы что, если zswap прекрасно работает?

маленького swappiness

Да, это серьёзное препятствие в достежении счастливой семейной жизни.

При 8G ram 4G zram это мало, замирание курсора на минуту это от того, что память кончилась. Да и zswap, подозреваю, ты не отключал. Ну и ограничивать cpu при использовании технологии, которая исключительно на него полагается, это никак не «Условия тестирования одинаковые». Вот моё тестировние:

• открыт браузер

# cat /sys/module/zswap/parameters/enabled
N
> # free -h; zramctl --output name,disksize,data,compr,algorithm,total,mem-used,comp-ratio,mountpoint
               total        used        free      shared  buff/cache   available
Mem:           7,6Gi       3,8Gi       3,4Gi       579Mi       1,3Gi       3,8Gi
Swap:           13Gi          0B        13Gi
NAME       DISKSIZE  DATA COMPR ALGORITHM TOTAL MEM-USED COMP-RATIO MOUNTPOINT
/dev/zram0    11,4G    4K   64B zstd        20K      20K     0,2000 [SWAP]

• запускаю игру, тормозов не ощущается вообще

> # free -h; zramctl --output name,disksize,data,compr,algorithm,total,mem-used,comp-ratio,mountpoint
               total        used        free      shared  buff/cache   available
Mem:           7,6Gi       6,6Gi       1,2Gi       1,8Gi       2,1Gi       1,1Gi
Swap:           13Gi       6,8Gi       6,6Gi
NAME       DISKSIZE  DATA COMPR ALGORITHM TOTAL MEM-USED COMP-RATIO MOUNTPOINT
/dev/zram0    11,4G  5,7G  1,4G zstd       1,4G     1,4G     3,9900 [SWAP]

• открывыю 10 вкладок дзена без блокировки рекламы, тормоза при открытии, игра идёт без тормозов

> # free -h; zramctl --output name,disksize,data,compr,algorithm,total,mem-used,comp-ratio,mountpoint
               total        used        free      shared  buff/cache   available
Mem:           7,6Gi       6,8Gi       744Mi       2,0Gi       2,3Gi       806Mi
Swap:           13Gi       8,9Gi       4,5Gi
NAME       DISKSIZE  DATA COMPR ALGORITHM TOTAL MEM-USED COMP-RATIO MOUNTPOINT
/dev/zram0    11,4G  7,8G  1,9G zstd       1,9G       2G     4,1033 [SWAP]

Снимок экрана от 2026-05-10 22-51-00.jpg

Если душнение проца до 800 мгц прекрасно, то ок. Пока не парюсь. Если можно использовать систему без файла подкачки, почему бы не использовать без него. Настроил автовыгрузку вкладок в файрфоксе чтоб не висели в памяти/не грели проц и результат 3.4гб использовано, кэш 3.3 гб. Зрам 0 байт использовано. Добавлять своп или что-то ещё не вижу смысла, если и так влезает.

Что вы за люди такие. Говорю же, что условия тестирования одинаковые. И zram и zswap имеют одинаковый алгоритм сжатия. Одинаково сжимают и держат сжатые данные в оперативной памяти. Но, с zram фризит, с zswap нет.

Zswap держит в кеше оперативной памяти те данные, которые используются прямо сейчас. Что не используется - сбрасывает на диск. Диск - nvme pci-e x4, то есть быстрый. И если внезапно нужны данные с него, то они моментально подкачиваются, фризов нет. Дистрибутив ubuntu 26.04.

Можно было бы выставлять какие то претензии к zswap, если бы у него не было сжатого пула в озу, а он есть - 900мб, и ничего не фризит. Коэффициент сжатия при этом 3,4 - 4.

Вывод, если есть ssd диск, а он сейчас есть у большинства, то лучше использовать zswap.

Ты для начала покажи zramctl и cat /sys/module/zswap/parameters/enabled а потом рассказывай об условиях тестирования.

У меня на 3100 МГц окрытые вкладки хотят проц грузить. А тут душнение проца и использование одного из самых медленных алгоритмов. Да и обращение к ram должно быть быстрее чем nvme, хотя если проц задушен

Ты для начала покажи zramctl и cat /sys/module/zswap/parameters/enabled а потом рассказывай об условиях тестирования.

Слушай, zswap включается опцией ядра в /etc/default/grub. Очевидно, что если тестировать zram то опцию эту надо снять, что и было сделано. И не поверишь, даже «$ update-grub» был выполнен. Как тебе такое а?

И ты не хочешь понимать, что условия никак не одинаковые. Ты делаешь zswap 4Гб и у тебя получается 8Гб рам - сжатый кэш + 4Гб свапа на диске, а потом делаешь zram 4Гб и у тебя получается 8Гб рам - сжатый кэш. И нагружаешь в память 12Гб, которых во втором случае тупо нету. Либо добавь к zram свап-файл на диске, либо, что правильнее и проще, сделай zram 8-12Гб, тогда условия будут одикаковые.

У меня на 3100 МГц

На 800мгц прекрасно всё работает. Если отпустить в 4,2Ггц, то ноут греется избыточно.

zswap не включается, а включен по умолчанию, в /etc/default/grub его не снимать надо, а явно отключать zswap.enabled=0. Как тебе такое а?

добавь к zram свап-файл на диске

А с чего ты решил, что фаил подкачки при тестировании zram куда то исчез? Он как висел, так и продолжил висеть. Тормозит он потому, что НЕ ЗНАЕТ, что из своего сжатого кеша скинуть на свап, а что оставить в озу. У zswap таких вопросов не возникает, потому и не тормозит.

Короче, ты очень криво тестируешь. В твоём случае вообще надо обычный swap без сжатия использовать.

zswap не включается, а включен по умолчанию, в /etc/default/grub его не снимать надо, а явно отключать zswap.enabled=0. Как тебе такое а?

Слушай, специально для тебя, ТОЛЬКО ЧТО, заморочился и убрал zswap.enabled=1 из опции ядра. Перезагрузился, и? И чё??? Чё ты мне тут втираешь какую то дичь?! По дефолту он выключен! Так что zram был в нормальных условиях и фризил.

$ cat /sys/module/zswap/parameters/enabled N

Короче, ты очень криво тестируешь. В твоём случае вообще надо обычный swap без сжатия использовать.

Тест как раз был нормальным. Условия одинаковые. Zswap справляется лучше.