В Linux сжатие памяти традиционно реализовано через zswap и ZRAM. Оба варианта работают на уровне swap: страничные ошибки, обращение к блочному устройству, программная декомпрессия. На Linux Plumbers Conference 2024 инженер Meta Gregory Price представил иную идею — CRAM (Compressed RAM service).
Что такое CRAM?
Упрощённо CRAM можно описать как: «ZRAM, но полностью в RAM и без swap». Важно, что CRAM не маскируется под блочное устройство. Вместо этого он создаёт приватный NUMA‑узел — своего рода «призрачный CPU‑домэн», которым ядро управляет стандартными механизмами управления памятью.
Согласно докладу и абстракту LPC, CRAM:
- Предоставляет покомпонентный (cacheline/byte) доступ к сжатой памяти
- Оставляет страницы отображёнными в page tables и присутствующими в page cache без страничных ошибок при чтении и без программной декомпрессии
- Даёт производительность, близкую к DRAM, в бенчмарках TAOBench и FIO
- Использует уже существующие механизмы ядра: защиту записи в таблицах страниц (COW, KSM) для анонимной памяти, Clean Cache для page cache, reclaim/demotion, memory ballooning, free page reporting, memory tiering и жёстко контролируемое NUMA‑распределение
Так как сжатые данные реально лежат в RAM и доступны напрямую, основной оверхед — это аппаратное сжатие, а не страничные ошибки и swap. На слайдах LPC CRAM в режиме только чтения обрабатывает около 489 млн операций/с против 1,1 млн у ZRAM — примерно 452× быстрее. При 20% записей он всё ещё около 5,4× быстрее ZRAM.
Резкое падение ускорения при записях связано с тем, что для записи нужно вызвать страничную ошибку и мигрировать folio обратно в исходный NUMA‑домэн: писать прямо в сжатые данные нельзя — это разрушит весь блок.
Нерешённый вопрос: сколько логической RAM у нас на самом деле?
Главная теоретическая проблема — учёт ёмкости. Степень сжатия сильно зависит от данных: страницы из нулей сжимаются идеально, а уже сжатое видео — почти никак. В абстракте LPC это прямо обозначено как открытая задача и область активных исследований.
Чтобы избежать каскадных сбоев, когда записи опережают возможности CRAM, в дизайне есть специальный «Chicken Bit» — флаг, который говорит ядру временно перестать полагаться на CRAM, пока оно разбирается с аллокациями. Это должно предотвращать так называемый «poison storm» — лавинообразный обвал из-за нехватки реальной ёмкости.
Зачем это сообществу Linux и разработчикам железа
Исходя из происхождения (Meta), основной фокус — крупные Linux‑серверы. Но ZRAM и zswap сегодня используются повсюду: от десктопов до устройств вроде Steam Deck и ARM‑плат, где многие дистрибутивы включают их по умолчанию.
Если CRAM доработают (в первую очередь — учёт ёмкости) и включат в мейнлайн‑ядро, то выигрыши могут получить и одноплатные компьютеры, и встраиваемые системы с малым объёмом RAM:
- Больше эффективной памяти без обращения к медленному swap на диске
- Существенно более быстрые чтения по сравнению с ZRAM
- Глубокая интеграция с существующей инфраструктурой NUMA, migration, ballooning
Для энтузиастов электроники и embedded‑разработчиков это в перспективе означает больше сервисов и контейнеров на маленьких Linux‑платах — с меньшим ударом по производительности.
Источник: Linux Plumbers Conference, Tom's Hardware
