Linux LZ4がv1.10.0に再同期、解凍が最大21%高速に

SamsungのエンジニアであるMichal Wilczynski氏は2026年9月25日、9本のパッチからなるシリーズを投稿した。Linuxカーネルに含まれるLZ4圧縮コードを、上流のLZ4 v1.10.0に合わせて最新化するものだ。カーネル内のコピーは上流から488コミット遅れている。この更新は、テストしたすべてのブロックサイズで解凍を最大21%高速化する。さらに、古いコードにある安全上の穴もふさぐ。

LZ4は、ファイルを小さくすることより速度を重視して作られた圧縮形式だ。カーネルは、データを絶えず圧縮・解凍しなければならない場面でこれを使う。圧縮メモリや読み取り専用ファイルシステムがその例である。

カーネルのLZ4はどれだけ遅れているか

カーネルはLZ4を外部ライブラリとして読み込まない。ソースツリーの中に独自のコピーを持っており、そのコピーが上流からずれてきた。Wilczynski氏のカバーレターによると、2つの部分はそれぞれ異なる時点で止まっている。

部分	カーネル内のバージョン	時期
解凍側	LZ4 v1.8.3	2018年
圧縮側	LZ4 v1.7.3	2017年
上流の目標	LZ4 v1.10.0	2024年7月22日

上流プロジェクトは2024年7月22日にv1.10.0をリリースし、「Multicores edition」と名付けた。リリースノートによると、600を超えるコミットが取り込まれている。目玉機能はマルチスレッド圧縮だ。辞書圧縮も安定版に昇格した。

境界チェックの問題

カバーレターで最も強い論拠は、速度ではなく安全性にある。カーネルがフォークしたLZ4_decompress_fast()関数は、自分がバッファの内側に書き込んでいるかを一切確認しない。「フォークされたLZ4_decompress_fast()には境界チェックがないため、壊れた入力は出力バッファの前後両方向にはみ出す」とWilczynski氏は書いた。

境界チェックとは、コードがメモリブロックの端を越えて読み書きするのを止めるテストのことだ。これがないと、壊れた圧縮データや悪意ある圧縮データによって、解凍処理が無関係なメモリを上書きしかねない。それはクラッシュやセキュリティホールにつながる典型的な経路だ。今回の再同期は、フォークしたコードを上流版に置き換える。

速度とサイズのトレードオフ

カバーレターは、4Kから256Kまで、テストしたすべてのブロックサイズで解凍が速くなったと報告している。LZ4ライブラリ単体での向上は次のとおりだ。

• 4Kブロック: 11%高速化
• 16Kブロック: 21%高速化（最大の向上）
• 64Kブロック: 17%高速化
• 256Kブロック: 10%高速化

読み取り専用ファイルシステムであるEROFS経由のテストでは、4Kで11%、64Kで14%の向上だった。

代償はサイズだ。x86_64では、コンパイル後のコードが45Kから89Kに増える。カバーレターは、その大部分を上流のより完全なパーサーによるものとしている。

このシリーズは、コードの保守方法も変える。カーネルは手作業で編集したフォークではなく、上流のファイルをそのまま持つことになる。「再同期はディレクトリのコピーで済むようになる」とWilczynski氏は書いた。

開発者にとっての意味

まず、そもそもカーネルでLZ4を使っているかを確認したい。カバーレターは4つの利用箇所を挙げている。zram、erofs、f2fs、そしてlib/decompress_unlz4だ。zramはRAM上に置かれる圧縮スワップデバイスである。EROFSは読み取り専用ファイルシステムで、F2FSはフラッシュストレージ向けに設計されたファイルシステムだ。

zramをLZ4で使っているなら、この変更が最も影響しやすい。zramへのスワップはメモリ不足のときに起こり、そのときはCPUサイクルの一つ一つが重要になる。そこで解凍が2桁の割合で速くなれば、システムの応答性が上がったと感じられる可能性がある。cat /sys/block/zram0/comp_algorithmを実行すれば、zramデバイスがどのアルゴリズムを使っているかがわかる。

EROFSでイメージを配布しているなら、11-14%の向上はファイルの読み込みに効く。多くの小さなブロックを一度に読む場面、たとえば起動時に最も効いてくるだろう。当てにする前に、自分のハードウェアでベンチマークを取ってほしい。カバーレターの数値は、その作者自身のテスト環境によるものだからだ。

小型デバイス向けにビルドしているなら、コードサイズが44K増える点に注意したい。フラッシュ容量に余裕のない組み込みカーネルでは、測定する価値がある。

本当にこの変更を望むべき理由は、境界チェックの修正だと考えてよい。古い高速デコーダーでディスクやネットワークからのデータを解凍する経路は、どれも入力を完全に信用している。シリーズが取り込まれるまでは、自分のカーネルコードではチェック付きの解凍関数を優先して使うのがよい。

これはレビュー中のパッチシリーズであり、マージ済みのコードではない。linux-kernelメーリングリストでメンテナーの返信を見守ってほしい。それによって、いつリリースに入るかが決まる。