zram, tmpfs и кеш

В 6.8 подвезут zswap writeback disabling — тогда своп номинально может быть подключен (просто потому что архитектурно frontswap так устроен)

В zram writeback прикостылили, а тут наоборот - откостыливают. Даже не знаю, что лучше) Есть идеи почему я должен выбрать zswap без writeback вместо zram?

Но новость крутая 👍️, даже достойна главной, мне кажется.

Есть идеи почему я должен выбрать zswap без writeback вместо zram?

Мне кажется, семантика writeback в zswap более соответствует тому, какой она должна быть по логике вещей. Zram жёстко ограничен своим объёмом (и сверху, и снизу), а writeback он делает когда сам захочет, сугубо внутри себя. Если окажется, что в zram’е все страницы «тёплые», а системе резко потребуется больше памяти, то ты будешь страдать.

Zswap же делает writeback при переполнении, сгружая самые холодные страницы и освобождая место в пуле для более горячих. Кстати, тот же чувак в соседнем патчсете подвёз в zswap шринкер, т. ч. теперь он сможет делать writeback не только при переполнении, но ещё и непосредственно при memory pressure.

А, извините, у тебя же «без writeback». Ну тогда не знаю. Чё там по аллокаторам?

Хз. Наверное мотивация была такая, что, типа, давайте сделаем одну систему сжатого кеша и забудем про zram. Это чисто догадки, я даже по ссылке не ходил пока)

Хотелось бы от тебя ещё какой-то комментарий к этому моему вопросу.

Комментарий следующий. Если zswap фейлит сжатие, то страница записывается в реальный своп и исчезает из памяти, медленно, но верно. Если zram фейлит сжатие, то происходит… что? Правильно, в ответ на попытку reclaim-а страницы происходит аллокация второй точно такой же страницы.

Т. е.:

Если же памяти для операции сжатия не хватает, то, очевидно, zram ничего не будет делать

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

Механизм reclaim на такое не рассчитан. В линуксе нет понятия «своп не смог, давайте попробуем следующий», следующий своп используется, только если текущий заполнен (даже если предположить, что следующий есть; будем честны, 99% пользователей swap-on-zram о том, чтобы добавить последним приоритетом реальный резервный своп, и не догадываются).

Если zram фейлит сжатие

В юзерском oom-killer (nohang) есть возможность включить zram_checking_enabled. Который срабатывает на ситуациях с несжимаемыми данными, если я правильно понял.
Здесь немного описания и видео срабатывания.

Костыль? Костыль. Подходит ли это под твой коммент, не знаю, это выше моей компетенции. )

В юзерском oom-killer (nohang) есть возможность включить zram_checking_enabled. Который срабатывает на ситуациях с несжимаемыми данными

Ты хакавлад должен мне новые глаза, но не совсем так. Оно срабатывает на ситуациях, когда ограничение на объём сжатых данных достигается быстрее, чем ограничение на объём несжатых данных. Я как раз думал упомянуть ещё и этот ахтунг, но задолбался печатать.

Суть в том, что с zswap у тебя есть ровно одно ограничение: compressed <= min(MemAvailable, max_pool_pct). Если оно достигается, zswap начинает как-то жонглировать страницами, какие-то вытесняя на диск, какие-то сжимая вместо вытесненных, и в целом ведя себя более-менее разумно.

А с swap на zram у тебя два независимых ограничения: одно uncompressed <= zram_disksize (со стороны свопа), а второе — compressed <= min(MemAvailable, zram_mem_limit) (со стороны zram). И эти ограничения принципиально не знают друг о друге, поскольку, как я уже сказал, в линуксовом свопе не предусмотрена возможность отказаться хранить данные. Если с точки зрения ядра в свопе есть свободное место, то он обязан принять страницу.

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

Мне кажется без физического свопа zram всё таки будет лучше. Но я считаю, что работа без физического свопа это принципиально не правильно если в принципе есть возможность куда нибудь его приткнуть. Т.е. zswap для ДЕ и серверов, а zram для всяких роутеров. Смартфоны спорно, я хз как андроид работает со свопом.

Соглашусь)

я считаю, что работа без физического свопа это принципиально не правильно

А вот Федора, сделавшая именно zram дефолтом, ошибается?

Если я не ошибаюсь, данный дистр, являясь одним из подразделений Red Hat, идет впереди всех сквозь «невежество и опасения нового», :) ‘грудью’ проталкивая «революционные» решения в области Linux.

p.s. Также, недавно обратил внимание на ее увлечение сборками в стиле Atomic.

являясь одним из подразделений Red Hat

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

идет впереди всех сквозь «невежество и опасения нового», :) ‘грудью’ проталкивая «революционные» решения в области Linux.

И это ещё не значит, что эти решения не *удацкие.

А вот Федора, сделавшая именно zram дефолтом, ошибается?

Вполне вероятно, что ошибается. Невозможно экспериментировать со 100%-ным хитрейтом.

Или, как вариант, решения отстают от технологий и переход на zswap в будущем.

все равно не пойму как считается zswap и фактически записанный на диск swap

130 tm4ig@sinx ~ % grep -i swap /proc/meminfo && free && swapon -s
SwapCached:       479404 kB
SwapTotal:       8388604 kB
SwapFree:        5196540 kB
Zswap:            963928 kB
Zswapped:        2735236 kB
               total        used        free      shared  buff/cache   available
Mem:        16077828     6344100      642168     1522184    11245440     9733728
Swap:        8388604     3192064     5196540
Filename                                Type            Size            Used            Priority
/swapfile                               file            8388604         3192064         -2

но при этом htop показывает https://ibb.co/yFVbS8r

сколько в реальности записано данных в своп-файл? 3Гб или 0?

сколько в реальности записано данных в своп-файл

(8388604 - 5196540) - 2735236 KiB

Тогда что показывает htop?

3.3.0+ — то же самое. Предыдущие — погоду на Марсе.

у меня archlinux, htop 3.3.0 и ядро 6.6.16, htop пишет 0к из 8г своп как на скрине

А, там у тебя ещё SwapCached, которого как раз 470 MiB.

Я не помню код наизусть, но скорее всего, SwapCached вычитается из значения индикатора.

Мне кажется без физического свопа zram всё таки будет лучше

да

В 6.8 подвезут zswap writeback disabling — тогда своп номинально может быть подключен (просто потому что архитектурно frontswap так устроен), но использоваться гарантированно не будет:

Перешел сюда по ссылке из другого топика, увидел этот коммент. Круто!

В AUR теперь даже пакет есть для этого

https://aur.archlinux.org/packages/zswap-disable-writeback

zswap-disable-writeback

Disable zswap writeback to use the swap space only for hibernation