# ページキャッシュカスタマイズ Linux などの OS が提供するページキャッシュ(page cache)の退避(eviction)・受け入れ(admission)方針を、アプリケーションのワークロード特性に合わせてカスタマイズする研究領域。既定の LRU 近似方式が「one-size-fits-all」で多様なワークロードに最適化できないという課題意識を出発点とする。([[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) ## 定義 Linux の既定ページキャッシュは、active/inactive の 2 本の FIFO リストによる LRU 近似アルゴリズムを用いる。scan ヘビーなワークロードや、頻度ベースの方が適するワークロード(YCSB の Zipfian 分布など)では、この一律な方針が性能を大きく損なう。ページキャッシュカスタマイズは、(1) カーネルを再コンパイル・モジュール追加せずに新しい退避アルゴリズムを実装する手段、(2) 複数アプリケーション間でポリシーが干渉しないための隔離機構、(3) カスタムポリシーがカーネルクラッシュやセキュリティ侵害を起こさない安全性、という3つの技術的要件を満たす必要がある。([[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) ## 横断的知見 - **1980年代の拡張可能カーネル(extensible kernel)の理念が、eBPF という安全なサンドボックス実行機構を得て初めて実用段階に達した**: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]] の関連研究整理によれば、VINO・SPIN・ACFS・XN(exokernel)といった 1980〜90 年代の拡張可能 OS/ファイルシステム研究は、アプリケーションによるバッファキャッシュ退避・受け入れ・プリフェッチ方針のカスタマイズを既に提案していたが、いずれも広く採用されずモノリシックカーネル(Linux 等)に取って代わられた。[[cache_ext]] は同じ目的を、eBPF の verifier による安全性保証と `struct_ops`/kfunc という現代的拡張インタフェースで再挑戦しており、「拡張可能カーネル」というアイデア自体は 40 年来のものであるのに対し、それを実用化する技術的手段(検証済みサンドボックス実行)が近年ようやく整った、という技術史的な位置づけが読み取れる。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) - **madvise()/fadvise() のような既存カーネルヒント機構は、実験的に「効かない」ことが繰り返し示されている**: cache_ext の評価では、FADV_DONTNEED・FADV_NOREUSE・FADV_SEQUENTIAL を GET-SCAN 混合ワークロードに適用しても既定方針からほとんど改善しなかった(Figure 11)のに対し、cache_ext のアプリケーション情報を用いた admission 方針は GET スループットを70%向上させた。これはカーネルが提供する「オプトインヒント」方式(ヒントの実際の効果がカーネル実装に依存し、バージョン間で変わりうる不透明な設計)の限界を、複数の具体的なオプション(3種の fadvise)を横並びで定量比較して示した点で説得力が強い。同様の「既存インタフェースは期待通り動かない」という知見は Linux の MGLRU(2021年に追加されたが未だデフォルト無効、GET-SCAN ワークロードでは既定 LRU よりさらに悪化)にも当てはまり、カーネル側の汎用改善よりもアプリケーション固有のカスタマイズの方が確実に効果を出すという構図を裏付ける。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) - **「唯一最良の退避方針は存在しない」ことが、マイクロベンチマークだけでなく Twitter の本番トレースでも定量的に確認された**: LHD・LFU・S3-FIFO・MGLRU・既定方針を Twitter cache workloads の複数クラスタで比較したところ、クラスタごとに最良方針が異なり(クラスタ34はLHD、クラスタ52はLFU、クラスタ17/18はMGLRU、クラスタ24は既定方針が最良でMGLRUはOOMで破綻)、単一方針による全ワークロード最適化が本質的に不可能であることが産業データで裏付けられた。これはキャッシュ研究における「adaptive caching」の必要性を、合成ベンチマークではなく実運用トレースで示した点で観測としての価値が高い。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) - **観測(cachestream)と制御(cache_ext)を同一の eBPF 基盤で対にすることで、診断→設計→検証のループが閉じる**: cachestream による RocksDB のページキャッシュ動作解析(コンパクションスレッドが folio 挿入・退避の大半を占め、フォアグラウンドの読み取りを圧迫している)から admission filter 方針を設計し、cachestream で改善(evictions -52.9%、hit rate +9.1pt)を再度確認するという開発フローが実演された。この「観測ツールと制御機構を同じ計装基盤で作る」設計は、[[eBPF]] concept が蓄積してきた「検証付き反復ループ」パターンの OS カーネル層での具体例である。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) ## 未解決の問い - cache_ext は現時点でファイルベースアクセスの評価に留まり、メモリマップ(mmap)ワークロードでの性能・オーバーヘッドは未検証。mmap 経由のアクセスパターン(アクセスビット参照)がカスタム方針とどう相互作用するかは今後の検証課題。 - cache_ext は退避・受け入れ方針に特化しており、readahead(先読み)や匿名メモリ(swap)方針のカスタマイズは対象外(論文は「調査中」と明記)。これらを同じ eviction list API に統合できるか、[[FetchBPF]] のようなプリフェッチ専用フレームワークとの統合可能性はどうか。 - LHD の確率計算のように eBPF が浮動小数点演算をサポートしないための整数近似は、他のキャッシュアルゴリズム(機械学習ベースの方針等)にどこまで適用可能か。eBPF native data structure(赤黒木等)の成熟が、この制約をどの程度緩和するか。 - cache_ext・sched_ext のような struct_ops/kfunc ベースのカーネル方針拡張が、OOM killer・transparent huge page 配置などへ提案されている(論文の関連研究で言及)。これらが将来アップストリームされた場合、cache_ext との相互作用(メモリ回収と page cache 退避の競合)はどう設計されるか。 - 本 wiki は複数のキャッシュ層(CDN・KVS・ページキャッシュ)を横断的に扱ってきた([[eBPF]] の LHD・S3-FIFO の言及)。ユーザ空間キャッシュ研究(TriCache 等)と OS ページキャッシュ研究(cache_ext)の役割分担・使い分け基準を整理する余地がある。 ## 関連 - ソース: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]] - 概念: [[eBPF]] / [[Linuxカーネルインタフェース]] - エンティティ: [[cache_ext]] / [[cachestream]] / [[sched_ext]] / [[RocksDB]] / [[Asaf Cidon]] / [[Columbia University]] / [[IBM Research]] ## 出典 - [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]](Linux ページキャッシュの eBPF カスタマイズフレームワーク cache_ext と観測ツール cachestream。8方針実装、最大70%スループット向上・58%テールレイテンシ削減)