MetaのGregory Price氏は2026年10月5日、プラハで開かれたLinux Plumbers Conference 2026で、ハードウェアが圧縮したメモリをLinuxから直接読み出す「CRAM」の設計と試験結果を発表した。既存のzramやzswapでは、スワップへ退避したデータを読み出す際、通常のメモリへ展開して戻す必要がある。CRAMは、圧縮されたメモリ上のデータをアプリケーションからそのまま読み出せるようにし、読み出し時のページフォルト処理を避ける構想だ。公開された試験では条件によってDRAMに近い処理速度を示したが、ハードウェアによる圧縮そのものの性能と、Linux側で必要になるメモリ管理のコストは分けて見る必要がある。

AD

圧縮メモリを直接読めると何が変わるか

zramとzswapは、メモリを節約する仕組みが異なる。Linuxの公式文書によると、zramはRAM上に圧縮ブロックデバイスを作り、スワップ領域や一時ファイルの保存先として利用する。一方、zswapは、スワップへ退避しようとするページを圧縮し、RAM上のキャッシュに保持する仕組みだ。キャッシュが上限に達すると、古いデータを背後のスワップデバイスへ書き出す。

ただし、zramをスワップとして利用する場合とzswapには、読み出し時に共通する処理がある。アプリケーションが退避済みのページへアクセスすると「ページフォルト」が発生し、Linuxは展開先となるページを通常のメモリ上に確保して、圧縮されたデータをそこへ戻してから処理を再開する。空きメモリが少なければ、新しいページを確保するために別のページを回収する処理も必要になる。

CRAMが想定するハードウェアは、圧縮されたメモリ領域へキャッシュライン単位やバイト単位で直接アクセスできる。そのため、アプリケーションの仮想アドレスと物理メモリの対応を記録するページテーブルに、圧縮メモリ上のページを残したままにできる。データの展開はハードウェア側が行うため、Linuxがページ全体を通常のDRAMへ戻す必要がない。アプリケーション自身が圧縮データを解読するのではなく、ハードウェアが通常のメモリアクセスとして見せる仕組みである。

読み出し時の経路を比較すると、違いは次のようになる。

方式 データを保持する場所・形 退避したデータを読むときの処理
zramをスワップに使用 RAM上の圧縮ブロックデバイス ページフォルトを処理し、通常メモリへ展開
zswap スワップページを保持するRAM上の圧縮キャッシュ ページフォルトを処理し、確保したページへ展開
CRAMの設計 直接アクセス可能なハードウェア圧縮メモリ 読み出し可能なマッピングを維持し、ハードウェア側で展開

zramとzswapの説明は公式文書、CRAMの説明はPrice氏の講演と開発コードに基づく。圧縮された領域へ移したページを読み出す場合の比較であり、zramをファイル保存用途に使う場合まで同じ動作になるという意味ではない。CRAMでは、読み出すたびに展開先となる通常メモリのページを確保しなくて済む点が重要になる。

Price氏が講演で示したKairui Song氏の測定例も、この狙いを説明している。1ページ当たりの処理時間は、ページフォルト処理が約1.92マイクロ秒、スワップ関連の管理処理が約1.04マイクロ秒、LZOによる展開が約0.32マイクロ秒だった。これは後述するzstdを使った比較試験とは別の測定例だ。それでも、圧縮・展開そのものをハードウェアへ移しても、ページの割り当てやスワップ管理に伴うコストが残ることが分かる。CRAMは、そうした読み出し経路全体を短縮しようとする仕組みである。

書き込みと割り当てを制御し、実際の容量を超えないようにする

圧縮メモリでは、OSから見える容量と、ハードウェアが実際に保持できるデータ量が一致するとは限らない。圧縮しやすいデータなら少ない物理メモリに多くの情報を収められるが、書き換えによって圧縮率が悪化すれば、同じデータ量を保持するためにより多くの領域が必要になる。Linuxが利用可能だと認識している容量を、実際のハードウェアが支えられなくなる可能性がある。

Price氏の設計では、まず書き込みを制限する。CRAMへ移したページは読み出し専用としてマッピングし、書き込みが発生した場合にはページフォルトを起こして通常のDRAMへ戻す。読み出しは圧縮メモリ上のまま行い、内容を書き換える場合だけ、容量が確実に確保された通常メモリへ移す仕組みだ。圧縮率を急激に悪化させる書き込みが無制限に発生すると、メモリ回収が追いつかなくなるため、こうした制御が必要になる。

CRAMへページを移す経路も限定する。アプリケーションから新しいメモリの割り当て要求があるたびにCRAMを直接使うのではなく、Linuxがメモリを回収する過程で、通常のDRAMからCRAMへページを移動させる。移動先には、通常のメモリ割り当て経路から切り離した「プライベートNUMAノード」を利用する。

NUMAノードは、Linuxがメモリを物理的な位置やアクセス特性に応じて管理するための単位だ。CRAM用のノードを通常の割り当て先から除外しておくことで、カーネル内の別の処理が意図せず圧縮メモリを使うことを防げる。

圧縮率の変化によって実際に使える容量が増減する問題には、OSが利用可能なメモリ量を調整する「バルーニング」で対応する。開発コードでは、デバイスドライバーが実際に達成している圧縮率をCRAMへ通知し、それに応じてメモリの一部を予約することで、Linuxから利用できる容量を調整する仕組みになっている。

さらに、ドライバー側から新しいページの受け入れを停止することもできる。圧縮メモリ上のページを書き込み禁止にする仕組みと、新しいページの流入を止める仕組みを組み合わせることで、想定以上に圧縮率が低下した場合でも容量不足が広がらないようにする設計だ。

このため、単純に圧縮率だけを見て「実質的にRAM容量が何倍になる」と考えることはできない。ページの読み書き権限、圧縮メモリへ移すタイミング、圧縮率が変化したときの容量調整やメモリ回収まで、Linuxとハードウェアの双方で管理する必要がある。

AD

DRAMに近い結果も、試験条件と分けて見る必要がある

Price氏が公開した比較試験には、ページフォルト処理のコストを切り分けるため、すべてDRAMを使って測定したという注記がある。そのため、圧縮ハードウェアそのものの速度や、省電力効果を実証した製品ベンチマークとして読むべきではない。示されているのは、DRAMを使った試験環境で、ページを読み出せる状態のまま維持するCRAMの設計によって、どこまでソフトウェア側の処理を減らせるかである。講演スライド11〜13

読み出し専用の比較では、匿名メモリの使用量を46 G、書き込み率を0%とし、CRAMなど各方式には36 Gの物理メモリを与えた。一方、性能上限の比較対象としたDRAMには、データ全体を収められる54 Gを割り当てている。容量の表記は、講演資料の「G」をそのまま用いている。

アクセス先に偏りがある場合と、全領域へ一様にランダムアクセスした場合の結果は次の通りだ。

アクセスの分布 CRAM（百万回／秒） 十分な容量のDRAM（百万回／秒） CRAM／DRAM
偏りあり（Zipf 0.99） 321 325 約98.8%
一様ランダム 489 498 約98.2%

読み出し専用の試験では、CRAMは十分な容量を持つDRAMの約98〜99%の処理速度を示した。比率はスライド11に記載された値から、321÷325×100と489÷498×100で算出したものだ。

ただし、同じ容量のDRAMと比較した結果ではない。DRAM側にはデータ全体を格納できるだけの容量を与え、性能上限として利用している。また、実際の圧縮ハードウェアに固有のアクセス遅延や圧縮率まで、この98〜99%という数字で保証されるわけではない。

書き込みが加わると、CRAMの処理速度は低下する。圧縮メモリ上のページを書き換える場合にはページフォルトを処理し、そのページを通常のDRAMへ戻す必要があるためだ。それでも、一様ランダムアクセスの試験では、書き込み率2〜20%の条件で、zramに対するCRAMの処理速度は37倍から5.4倍だった。

ただし、読み出し専用の場合の差と、書き込みを含む場合の差を同列に扱うべきではない。また、アクセス先に偏りがある試験では、書き込み率10%と20%でzramがメモリ不足によって終了している。いずれも、この特定の試験条件で得られた結果である。

zswapとの性能差については、さらに注意が必要だ。Price氏は、約90ミリ秒に及ぶ原因未解明のメモリ回収停止が発生したため、zswapの測定結果は十分に妥当とは言えないと記している。このグラフの倍率だけを根拠に、CRAMが一般的にzswapより何倍高速だと結論づけることはできない。

CRAMでスワップインが0回になった場合でも、メモリ待ちがなくなるわけではない。書き込み率20%の試験では、直接メモリ回収による停止が発生し、PSIでタスクが完全にメモリ待ちとなった時間を示す「memory full」は35〜37秒だった。

スワップインと、書き込みによって発生するページフォルトは別の処理だ。読み出しの多いデータを圧縮メモリ上に残せる利点をどこまで生かせるかは、ワークロードの書き込み頻度や、どのページをDRAMへ戻すかによって変わる。

匿名メモリからページキャッシュへ、なお続く実装作業

現在の開発コードは、ヒープなどファイルを直接の保存元としない「匿名メモリ」に加え、書き換えられていないファイルページも対象としている。つまり、ファイル内容をメモリ上に保持するページキャッシュにもCRAMを利用しようとしている。

ただし、ファイルページは複数の経路から書き換えられるため、匿名メモリを単純に読み出し専用とする場合よりも制御が複雑になる。変更されていないページであれば、メモリから破棄した後でもファイルから再度読み込める。一方、そのページを書き換える場合には、通常のDRAMへ戻してから処理する必要がある。

Linuxにすでに存在する仕組みをどこまで再利用できるかも、開発上の焦点となっている。Price氏は講演案内で、CRAMに必要な機能の大半は現在のLinuxカーネルに存在するか、過去に実装されたことがあると説明している。ページテーブルによる書き込み保護や、異なるメモリ階層間でページを移動させる既存機能を活用する一方、割り当て先を厳密に管理できるプライベートNUMAノードが、CRAMを統合するための重要な基盤になる。

ただし、この基盤部分とCRAM本体では、Linuxカーネルへの統合に向けた進捗が異なる。2026年7月20日に公開された第5版の提案では、プライベートメモリノードを通常のメモリ割り当てから隔離し、回収や移動など許可する機能を個別に指定する仕組みが示された。一方、CRAMそのものの実装例は、このパッチ群から切り離して別途提出する方針が明記されている。

9月上旬の開発者メーリングリストへの投稿でも、Price氏はCRAMの開発ブランチを維持していると説明しており、まず匿名メモリだけを対象とする部分の方が、上流カーネルへの提案として検討を進めやすいとの見方を示している。

10月の講演は、圧縮されたメモリを通常のメモリに近い形でLinuxから扱うために、どのようなカーネル側の仕組みが必要かを議論する場だった。CRAMがLinuxへ正式採用されたことや、対応ハードウェアの一般提供を発表したものではない。現在のPCでzramの設定を変更するだけで、同じようにハードウェア圧縮メモリを直接利用できるわけでもない。

今後、実機で確認すべき条件は明確だ。圧縮メモリへ直接アクセスした場合に読み出し遅延がどこまで増えるのか、データの内容によって実際に使える容量がどう変化するのかを測る必要がある。書き込みが増えた際に、DRAMへのページ移動やメモリ回収が十分な速度で追いつくかも重要になる。

こうした条件を満たし、対応ハードウェアとLinux側の実装が整えば、読み出し中心の大規模なデータを、アクセスするたびに通常のDRAMへ戻すことなく扱える可能性がある。