zram, tmpfs и кеш

Не ссы, не будет оно такое кэшировать. Это решается драйвером ФС.

понимает ли операционная система что эти файлы и документы уже в озу и будет ли она пытаться их (фактически повторно) кешировать в оперативную память

Нет, не понимает. Да, будет.

P. S.

xfs на zram в ОЗУ

(ну или в более простом случае tmpfs)

Это два совершенно разных случая. Tmpfs не может быть «на zram» или «не на zram».

тогда разделим два случая:

• xfs/ext4 на zram
• обычная tmpfs (я и имел ввиду изначально что она не на zram будет)

Все дисковые файловые системы будут кэшироваться,
tmpfs - нет.

tmpfs это и есть прокешированные файлы, не отображённые на диск.

В сучае fs/zram - будет. Но отбросит кеши в первую очередь когда прижмёт. Главное не использовать сложные и фичастые ФС, ext2 скорее всего оптимально.

в ext2 не работает discard поэтому при удалении файлов с фс на zram свободное место не освобождается

Ну....

Может быть это и аргумент.

<любая ФС> на zram

Нет, не понимает. Да, будет.

обычная tmpfs

Обычная tmpfs ­повторно кэшироваться не будет, т. к. tmpfs — это и есть файловый кэш (в буквальном смысле).

рационально ли использовать тогда с учётом компрессии (1.5-2 раза) zram+классическая фс или разумнее использовать обычный tmpfs т.к. преимущества сжатия нивелируются кешированием?

Используй tmpfs и не городи сложные механизмы на ровном месте. В zram положи свап, и tmpfs (вроде бы, поправьте если не так) при необходимости сожмётся в него.

Разумнее всего использовать tmpfs + zswap. Всё остальное — костыли на велосипедах.

Единственное исключение — это если ты ожидаешь, что данные большую часть времени будут холодными, а memory pressure — достаточно большим, чтобы эти данные всё время между обращениями к ним проводили в сжатом виде. Тогда ФС на zram выгоднее. Но ни в коем случае не «zram как swap».

Но ни в коем случае не «zram как swap»

С чего это вдруг? zram это более новый модуль который по факту задепрекейтит zswap со временем т.к. умеет всё что он и больше.

Но ни в коем случае не «zram как swap».

Почему? В частности, если просто нужен своп, который практически никогда не будет использоваться.

Upd. Умеет ext2 discard

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

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

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

Ну, лично в моём случае это только при какой-то быстрой утечке, коих я не видел давно. Но вообще zram нередко используют в тех же домашних роутерах, и вроде нормально работает, а памяти там не хватает часто. Или вот в Fedora уже какое-то время как перешли на zram: https://fedoraproject.org/wiki/Changes/SwapOnZRAM

ни в коем случае не «zram как swap»

«zram, 9Gb ram, в tmpfs лежит файл размером 780Gb», Zram и сборка в памяти. (комментарий).

Это наглядный и, наверно, тестовый пример от @hakavlad. А насколько такое применимо в реальных условиях, не могу сказать.

9Gb ram, в tmpfs лежит файл размером 780Gb

Я и без zram так могу: truncate -s 780G /tmp/bigfile :-)

zram это более новый модуль который по факту задепрекейтит zswap

А ты, я смотрю, так и не отучился с умным видом рассуждать о том, о чём не имеешь ни малейшего понятия:

$ git log --pretty=tformat:'%ai' -- mm/zswap.c | tail -n1
2013-07-10 16:05:03 -0700

$ git log --pretty=tformat:'%ai' -- drivers/staging/zram | tail -n1
2010-06-01 13:31:24 +0530

Какой хитрый, staging zram и прод-zswap сравнил.

Вот правильная инфа:

Две страницы разработки прод-zram с 2014 по 2024 1 2

Одна страница разработки zswap с 2013 по 2023 1

Да, в обоих до сих пор правки идут, но целесообразность использования zswap таки теряется.

Всё остальное — костыли на велосипедах

Ну мне кажется для SSD все же zram лучше. Тут же на диск ничего не пишется, а с SSD это важно. Просто создается устройство, резервируется память для него и все пишет в память.

zram вполне умеет записывать на диск, у него backing device есть

tmpfs очень хорошо свопится, в т.ч. с помоью zswap/zram. Но есть негативный момент: в случае свопинга при обращении к данным они сначала должны быть прочитаны из свопа вытеснив туда что то другое (2 операции), а потом снова положены в своп (ещё 1 запись).

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

Если памяти с избытком, мне кажется лучше всего tmpfs + zswap + небольшой физический своп на всякий случай. Если памяти в недостатке, возможно лучше фс + zram + baking_dev и zswap + физический своп для системы. А возможно просто вернуть данные на диск.

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

ППКС, всё идеально расписал

Zswap предназначен для работы с файлом подкачки насколько я знаю. То есть запись на диск в любом случае происходит. А zram не предназначен для этого. То есть Zswap работать без swap не будет, насколько я знаю. Грубо говоря, если я хочу в большей степени исключить запись на диск, то насколько я понимаю zram в этом плане лучше.

Вот нихрена. zswap это эмулятор блочного устройства, который с помощбю пары-тройки костылей был дотянут до уровня zswap. А zswap это специальная подсистема ускорения свопинга, изначально разработанная для этого.

Единственная причина большей популярности zram - поисковики выдают инструкции с его участием в 95% случаев.

Не переобувайся в прыжке. Разговор был о том, кто из них новее. А staging или нет — значения не имеет, это просто каталог в дереве исходников. Его оттуда перенесли в основное дерево без каких-либо изменений, просто потому что нашёлся новый мейнтейнер.

насколько я знаю

Ну, ты знаешь неправильно. (Точнее, полуправильно: swap должен быть, но это не означает, что данные будут в него записываться.)

То есть запись на диск в любом случае происходит

Нет, это не так. Не спорь с теми, кто эти исходники лично руками правил :-)

Нет, это не так

В таком случае вы можете ссылку в исходниках ядра кинуть где это указано? Я вам конечно верю, но просто принимать на веру оно как-то не очень хорошо.

Да, в обоих до сих пор правки идут, но целесообразность использования zswap таки теряется.

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

А сколько zswap до вноса в официальное дерево был в бета-разработке где-нить в приватной репе? Тогда это тоже надо учитывать.

То есть запись на диск в любом случае происходит.

Нет, это не так.

Имеется в виду, наверно, что у zswap есть буфер в памяти, и пока он не заполнится сжатыми данными, сброса на диск не будет. Т.е. может быть так, что zswap работает, а сброса нет.

Как пример, когда zswap включен, но ram на компе с избытком для повседневных задач.

Прошу:

[Zswap] takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool. <…>

Zswap evicts pages from compressed cache on an LRU basis to the backing swap device when the compressed pool reaches its size limit.

Здесь этого явно не сказано, но из того, что он «evicts pages <…> to the backing swap device» следует, что до вытеснения они находятся в памяти.

Zswap использует подсистему frontswap, про которую написано здесь:

Once a page is successfully stored, a matching load on the page will normally succeed. So when the kernel finds itself in a situation where it needs to swap out a page, it first attempts to use frontswap. If the store returns success, the data has been successfully saved to transcendent memory and a disk write and, if the data is later read back, a disk read are avoided. If a store returns failure, transcendent memory has rejected the data, and the page can be written to swap as usual.

(выделение моё)

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

Вот кстати zswap таки новее: В ядре 4.4 он всё ещё в «экспериментальном», а более оптимальые алгоритмы упаковки и размещения туда ещё позже занесли.

Сейчас ситуация идёт к тому, что его просто включают по умолчанию в некоторых дистрибутивах - вроде бы дебиан и арч, на 10% озу.

критические ситуации будут проходиться с ошибкой

У меня китайский SSD(Netac NV 7000), на него дополнительно писать вообще не вариант, умрет. Я на него даже дышать лишний раз боюсь. Может попозжет поправлю, когда будет ещё HDD побольше размером.

Я где то в районе декабря-нового года отключил от Малины-3 своп-ссд на 120гб и воткнул вместо него 8Гб флешку. Теоретически это конечно ужастный вариант и всё такое, но с удлиннённой до 64 блоков очередю сброса свопа на диск (и zswap разумеется) где то до 1,5Гб занятой памяти (из 942М физической) свопинг не ощущается вообще, а трешинг наступает только после этого +50% лимита и только при открытии сразу 2 вкладок (или конкуренции 2 приложений). Если свопиться менее радикально, то абсолютно что угодно может стать аварийным своп-разделом.

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

https://lkml.kernel.org/r/20231207192406.3809579-1-nphamcs@gmail.com

Netac NV 7000

Ну хз. У него кажется была очень интересная истоия успеха с подменой контроллера и чипов памяти, но эт всё таки TLC а не QLC, да и ресурс записи у него заявлен в 700 объёмов, т.е. в 1,5 раза выше среднебюджеток.

У меня DEXP M3 120Гб, ~4-6 лет под свопом на Пи3, полёт нормальный (теперь под свопом на пи4). Судя по всему там настоящий MLC и может быть даже настоящий Phison. И заявлен ресурс в 500 объёмов.

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

а это же ты к htop прикрутил мониторинг zswap недавно? если free показывает в свопе 20 мб, а htop (последней версии) 1000кб кому из них верить?

Да, я прикрутил.

Верить htop-у. В линуксе zswap-нутые страницы учитываются так, как будто они в свопе (т. е. декрементируют SwapFree), но на самом деле они физически не в свопе. Поэтому для получения правильных (соответствующих здравому смыслу) показателей из SwapTotal-SwapFree нужно вычитать Zswapped.

Что то я не понял, оно будет оставлять в памяти страницу, компрессия которой оказалась недотаточно высокой?

Да. Или если пул заполнен — тоже будет оставлять в памяти.

Просто если есть решение сбрасывать, значит уже надо сбрасывать.

Ну, иногда есть необходимость сделать так, чтобы система вела себя точно так же, как будто своп выключен, но со сжатием. Патчсет про это.

а для zswap нужно чтобы реальный свап был равен или больше zswap max_pool_percent т.е. для системы с 16 ГиБ ОЗУ и max_pool_percent 25% свап нужно делать не менее 4 Гб?

нужно чтобы реальный свап был равен или больше

Впервые вижу человека, задающегося вопросом о пределах создаваемого раздела/файла для zswap. Обычно просто ставят столько, сколько считают нужным, исходя из потребностей системы.

Имхо, отличие zswap от привычного свопа, только наличием буфера в памяти, а значит меньшим i/o.

upd. В случае файла, есть возможность сделать динамическим, когда по потребности создается новый в дополнение к старому.
В пакете systemd-swap была такая фича, пользовался одно время.

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

Т. е. если в системе 16 ГиБ ОЗУ, max_pool_percent=25 и ты оцениваешь степень сжатия как 0.2, то своп должен быть 20 ГиБ.

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

Оригинально.

Пруф? И что не наоборот.

Но ни в коем случае не «zram как swap».

попытка высвободить память приведёт к уменьшению количества доступной памяти

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