10月7日、Zak Killianが「New Linux tech compresses memory in RAM, as RAM, for 452x speedup」と題した記事を公開した。Metaのエンジニアが開発したLinux向け新メモリ圧縮技術「CRAM」が、既存のZRAMと比較して読み取り性能で最大452倍の改善を達成したという内容だ。
452倍という数字は読み取り専用の最良ケースだが、絶対値で見ると毎秒4億8900万オペレーション対110万オペレーションと、桁が3つ異なる。AIワークロードの急拡大でデータセンターのメモリ消費が年々増す中、圧縮メモリの性能が実用に耐えるかどうかはMetaのような大規模オペレーターにとって切実な問題であり、CRAMはその答えの一つとなりうる。
ZRAMの何が遅いのか──ボトルネックはスワップにあった
Linuxにおける圧縮メモリの主流実装はzswapとZRAMの2つだが、いずれも根本的には「スワップレイヤー」の機能として実装されている。つまり、圧縮データにアクセスするたびにブロックデバイスとしての振る舞いが介在する。
MetaのGregory Priceらが注目したのは、圧縮メモリの性能ペナルティの大部分は圧縮処理そのものではなく、ページフォルトとスワップ動作から来ているという点だ。圧縮自体のコストは小さい。問題はスワップという迂回路にある。
そこから生まれたのが「ZRAMをスワップ経由ではなく、完全にメモリ内で直接動かしたらどうか」というCRAMのコアアイデアである。
CRAMの仕組み──プライベートNUMAノードとしてメモリを管理する
CRAMはブロックデバイスのふりをするのではなく、プライベートNUMAノード（物理CPUを持たない仮想的なメモリノード）として振る舞う。NUMA（Non-Uniform Memory Access）はLinuxカーネルがメモリをノード単位で管理する仕組みで、CRAMはこの既存の枠組みに乗ることで、ページマイグレーションやバルーニング（仮想環境でのメモリ動的調整）といったLinux標準のメモリセマンティクスをそのまま活用できる。
圧縮データはRAM上にキャッシュライン・バイト単位でアクセス可能な形で保持されるため、読み取りはほぼハードウェアオフロードの圧縮コストのみで済む。Priceのスライドには「CRAMはDRAMスピードで動作する」とある。
実際の数字を見ると、読み取り専用の場合：
- CRAM：最悪ケースで毎秒4億8900万オペレーション
- ZRAM：毎秒110万オペレーション
452倍という数字の背景がわかる。
書き込みを含む場合でも、20%書き込み混在のワーストケースでZRAM比5.4倍を維持する。書き込み時に性能が落ちる理由は、圧縮データへの直接書き込みはデータ破壊を招くため、元のNUMAドメインへのページフォルトとfolioマイグレーション（カーネルの大粒度ページ管理機構）が必要になるからだ。
未解決問題──「Chicken Bit」と「ポイズンストーム」
圧縮メモリの難しさの一つは、「論理的なRAM容量がどれだけ確保できるか事前にわからない」という問題だ。ゼロばかりのデータは高圧縮できるが、すでに圧縮済みのデータはほぼ縮まらない。圧縮率はデータ次第で大きく変動するため、どの時点でメモリが枯渇するかの予測が困難になる。
CRAMはこの問題をまだ解決していない。発表スライドでも「未解決の研究課題」として明示されている。
その代わりに実装されているのが「Chicken Bit」だ。CRAMがアロケーション管理で手一杯のとき、Linuxに対してCRAMへのアクセスを一時停止させる仕組みである。書き込みがCRAMのアロケーション能力を超えた際に発生する連鎖障害──スライドでは「ポイズンストーム」と呼ばれる──を防ぐための安全弁として機能する。
Linuxカーネル開発コミュニティでは、このような「アドホックな安全弁」をメインラインに取り込む際に設計上の懸念が議論されることが多い。CRAMが正式なパッチとしてLKML（Linuxカーネルメーリングリスト）に投稿された段階で、こうした点がどう審議されるかも注目される。
対象と現在地
CRAMはMetaの大規模Linuxサーバーを主な対象として開発されているが、ZRAMとzswapはSteam Deckのような低スペックマシンも含めてLinuxエコシステム全体で広く使われており、多くのディストリビューションがデフォルトで有効化している。CRAMの設計思想がより広い用途に展開されれば、影響範囲は大きい。
発表はLinux Plumbers' Conference（プラハ）で行われた。Phoronixによるセッション情報をもとにTom's Hardwareが解説したものであり、記事執筆者はカンファレンスへ直接参加していない点は留意が必要だ。カーネルへのマージには実装上の未解決課題が残っており、現時点では研究・提案段階にある。
詳細はNew Linux tech compresses memory in RAM, as RAM, for 452x speedupを参照していただきたい。
