eBPFのCPUコストを約90%削減したメモ化、AI生成ではない
Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
eBPFセキュリティエージェントの性能をプロファイリングしたところ、ポリシー適用よりもファイルオープン時のパス走査が高コストだと判明。inodeベースのLRUキャッシュでメモ化し、カーネルCPUサイクルを280億から30.3億へ削減。ハードリンクはリンク数で判別して安全にフォールバックする。
キャッシュにより、最初のルックアップ以降はパス走査のコストがほぼ消え去り、is_restricted_filepathとpath_check_callbackはそれぞれ約0.02%にまで縮小した。
HNでの議論
17- Allybag
90%高速化されるケースというのは、毎回全く同じファイルを開く場合のようだ。これはこのキャッシュの恩恵を最も受ける、あまり標準的とは言えないユースケースに思える。同じファイルを二度と開かないような例では、同じことをしつつキャッシュに書き込む分、おそらく以前よりわずかに遅くなるだろう。
つまり「パフォーマンスコストを90%削減！」とも「パフォーマンスコストをわずかに増加」とも見出しにできて、どちらも正しい。だが、どちらもこの変更を適切に説明しているとは思えない。
- danudey
この記事にはとても混乱した。メモ化はeBPFの世界では新しいのか？著者は最近それを知って使ってみたかっただけなのか？
現実には、この記事はeBPFとLinuxファイルシステムセマンティクスの制約の中で、パスとポリシーのマッピングを正しくキャッシュすることについて書かれている。『eBPFにおけるメモ化の何が新しくて面白いのか？』と考えるのではなく、その文脈で記事を読めば、ずっと興味深いものになる。
私ならおそらく『eBPFでファイルシステムパスのキャッシュキーを計算する』といったタイトルにしただろう。それが解決されたクールで興味深い問題だからだ。
- ComputerGuru
パスのみのルールは、ファイルをロードする際に別のパスに見せる多くのアプローチ、たとえばバインドマウントなどをどう扱うのか？