著者 Linux kernel 7.2の新機能とVPSへの影響
Linux kernel 7.2ではCONFIG_SCHED_CACHEが追加され、同じLLCを共有するCPUへスレッドを配置します。複数LLCのNUMA構成が見えないVPS guestでは、多くの場合効果がありません。
Linux kernel 7.2 の新機能
Linux kernel 7.2 は 2026 年 8 月 16 日にリリースされました。注目すべき変更は、 新しい CONFIG_SCHED_CACHE オプションでビルドされる cache aware scheduling です。scheduler は、同じ last level cache (LLC) を共有する CPU に、同一プロセスのスレッドを配置しようとします。このリリースで、ワークロードを CPU に配置する方法が変わるのはこの点だけです。
7.2 のその他の変更を 1 行でまとめると、ext4 fast commit パスの再設計、MGLRU（multi-generational least recently used メモリー回収コード）の改善、インライン block device encryption 用の新しい dm-inlinecrypt device mapper target の追加、そして kernel ソースから最後の strncpy() 呼び出しを削除したことです。
この主要機能が役立つかどうかは、1 つの事実で決まります。そのため、最初に説明します。cache aware load balancing は、NUMA（non-uniform memory access）node に複数の LLC がある場合にのみ有効になります。通常、VPS guest にはその構成が示されません。そのため、多くの guest ではコードが組み込まれていても、実際には動作しません。これを確認する方法は、後述の「VPS guest にこの構成が見えるか」で 2 つのコマンドを使って説明します。
このページの技術的な記述はすべて、2026 年 8 月 18 日に確認した 7.2 changelog と cache aware scheduling の patch series に基づいています。末尾付近にソースを記載しています。使用中の kernel の動作と照合できます。
スケジューラがキャッシュを把握する必要があった理由
最新のサーバーソケットには、単一の最終レベルキャッシュがあるわけではありません。AMD EPYC パッケージは複数のコアコンプレックスで構成され、各コンプレックスが独自の L3 を持ちます。最近の Intel Xeon も、1 つのソケットを複数のキャッシュドメインに分割しています。そのため、1 つの NUMA ノードに 4 個、8 個、またはそれ以上の個別の LLC が存在し、同じプログラムの 2 つのスレッドが異なる LLC に配置されることがあります。
この配置には時間的なコストがあります。異なる LLC にある 2 つのスレッドが 1 つのページを共有すると、各キャッシュはそのキャッシュラインのコピーを保持します。一方で書き込みが発生すると、もう一方のコピーが無効化されます。そのため、次の読み取りではインターコネクトを経由するか、メインメモリまでアクセスする必要があります。これがキャッシュバウンシングです。これは CPU のアイドル時間ではなく、待機に費やすサイクルとして現れます。そのため、ロードアベレージを監視しているだけでは見落としやすくなります。
7.2 より前のロードバランサーは、負荷、使用率、アイドル状態の CPU に基づいてタスクを配置していました。「この 2 つのタスクは同じメモリを読み取る」と示す入力はありませんでした。7.2 では、計算コストがかからない近似を使って、この情報を追加します。プロセスのスレッドは 1 つのアドレス空間を共有するため、データも共有する可能性が高いとみなします。
カーネルが優先 LLC を選択する仕組み
この追跡情報は、1 つのアドレス空間を表すカーネル構造体である mm_struct に、プロセス単位で保持されます。カーネルは定期的に、そのプロセスのスレッドがどこで実行されているかをサンプリングし、各 LLC についてプロセスのどれだけが存在するかを数えます。最も多くの実行状態を保持する LLC が、プロセス全体の優先 LLC になります。その単一の値を、後続の判断が参照します。
その後、2 つの処理経路がこの情報を使用します。ウェイクアップ時、スケジューラはノード内のアイドル CPU を任意に選ぶのではなく、プロセスの優先 LLC に属する CPU を優先します。負荷分散では、タスクをスケジューラグループ間で移動する必要がある場合、移動先の LLC をすでに優先しているタスクを優先的に移動します。また、タスクを優先 LLC から離す移動は避けます。
この機能では、ガードレールが機能そのものと同じくらい重要です。ビジー状態のプロセスの全スレッドを 1 つのキャッシュドメインに集約すると、そのドメインだけが過負荷になり、ソケットの残りの部分がアイドル状態になる可能性があるためです。調整可能な値は、カーネルのデバッグファイルシステムである debugfs の /sys/kernel/debug/sched/ にあります。
llc_aggr_toleranceは 0 から 100 の値で、カーネルがどの程度強く集約するかを設定します。0にすると、実行時の cache aware scheduling が無効になります。1は慎重な設定です。RSS（resident set size、プロセスが常駐させているメモリ）が LLC より大きいプロセス、または LLC のコア数を超えるスレッドを実行するプロセスは、現在の配置のままにします。100は、サイズやスレッド数に関係なく集約します。llc_overload_pctは、優先 LLC をビジー状態とみなす平均使用率のしきい値です。デフォルトは50です。llc_imb_pctは、優先 LLC がその過負荷しきい値を超えた後に、集約を目的とした移動によって生じる不均衡の上限です。デフォルトは20です。llc_epoch_periodは、占有状況を収集する間隔です。デフォルトは10ms です。llc_epoch_affinity_timeoutは、非アクティブなプロセスが優先 LLC の情報を保持する時間です。この時間が経過すると、カーネルはその情報を破棄します。デフォルトは50ms です。
変更する前に、現在の値を確認してください。ディストリビューションによってデフォルト値が異なる場合があるためです。sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
効果が見込めるワークロードと、見込めないワークロード
以下の数値は、パッチシリーズとともに公開された測定値です。サーバークラスのハードウェアで測定され、一部は許容値の設定を積極的な値まで調整しています。ベアメタル環境での良好なケースとして扱い、使用している環境で同じ結果が得られると考えないでください。
The data behind this chart
[
{
"label": "hackbench, 1 group, Xeon Sapphire Rapids",
"gain_pct": 30.57
},
{
"label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
"gain_pct": 37.78
},
{
"label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
"gain_pct": 44
}
]単一グループで実行した Hackbench は 30.57% 改善し、AMD Genoa での ChaCha20 スループット測定は 44% 改善しました。3 件の結果はすべて、測定者がエンドツーエンドで管理する、複数の LLC を備えたサーバーハードウェアで取得されています。
効果が見込めるワークロードには、次の特徴があります。
- 1 つのプロセス内で複数のスレッドを使用しているため、グループ化の対象がある。
- それらのスレッド間で実際にデータを共有しているため、キャッシュラインの移動コストを実際に負担している。
- ワーキングセットが 1 つの LLC に収まる。キャッシュより大きいプロセスを移動しても、キャッシュ局所性は得られない。
- マシンに余剰容量があり、スケジューラーが次のスレッドの配置先を選択できる。
一方、効果が得られないケースは次のとおりです。
- マシンがすでに完全に負荷を受けている。すべての CPU がビジーで配置が強制されるため、報告された効果は小さくなる。
- シングルスレッドのプロセス、およびデータを共有しない独立したプロセスのプール。
- LLC より大幅に大きいワーキングセット。慎重な
llc_aggr_tolerance設定では、このケースを意図的に対象外にする。 - 1 つの LLC だけを報告するノード。この機能はまったく有効にならない。
コストも発生します。パッチシリーズでは、この点を明示しています。占有状況の収集はタスクのコンテキスト内で実行されるため、その処理によってタスクのユーザー空間への復帰が遅れ、リクエストレイテンシーが悪化した測定結果もあります。平均スループットが向上しても、集約によってレイテンシーのばらつきが大きくなる場合があります。平均値ではなくテールレイテンシーを重視する場合は、実際の環境でテールレイテンシーを測定してください。
VPS ゲストにも影響するのか
答えは、2 つの事実で決まります。
1 つ目は、この機能がトポロジーを条件として有効になることです。Cache aware load balancing は、1 つの NUMA node 内に複数の LLC がある場合にだけ有効になり、kernel はトポロジーの初期化時にその情報を記録します。node が単一の LLC を報告する場合、tunables をどのように設定しても、cache aware の処理経路は無効なままです。
2 つ目は、ゲストが認識する cache topology はホストのものではないことです。ゲストが認識する構成は、hypervisor が提示する CPU model によって決まります。通常、デフォルトの KVM (kernel based virtual machine) ゲストには、ホストの実際の L3 配置は渡されません。そのため、ゲストは単純化された構成を前提に動作します。
自分のゲストが認識している構成を確認します。
systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -uindex3 は、ほとんどの x86 CPU における L3 cache です。すべての vCPU を列挙する行が 1 行だけの場合、ゲストは単一の LLC を認識しています。そのため、この機能が配置を調整する対象はありません。No such file or directory は、ゲストに L3 が公開されていないことを示します。この場合、ゲストは下位の cache level を last level として扱います。その境界は、silicon の実際の境界ではなく、hypervisor が作成したものです。
さらに、二重のスケジューリングがあります。これは、どの tenant にも当てはまる重要な注意点です。ゲストの kernel は thread を vCPU に配置します。ホストの kernel は、それらの vCPU thread を物理 core に配置します。ゲストが 4 つの thread を vCPU 0 から 3 に意図的にまとめても、それは 4 つのホスト thread に対する希望を示しているだけです。ホストは、それらを異なる物理 cache domain に配置することも、後から移動することもできます。ゲストの判断が間違っているわけではありません。ただし、それが最終的な配置ではありません。これは、ノイジーネイバーが vCPU に残す steal timeを生むのと同じレイヤー境界です。
では、この機能は VPS tenant にどこまで影響するのでしょうか。場所は 2 つあります。dedicated core や、実際の構成が合成されたものではなく、layout が passthrough された大規模な instance など、実際の topology が提供されるプランでは、ゲスト scheduler は実在する hardware を対象に判断します。もう 1 つは provider 自身のホスト kernel です。そこで vCPU thread の cache aware な配置を活用できるのは provider であり、tenant ではありません。cache layout は architecture によっても異なるため、Arm VPS と x86 VPS の比較では、さらに 1 つの変数になります。
ゲスト内で cache の動作を測定することは、物理 hardware 上で測定するより困難です。perf stat -e cache-misses は、hypervisor が PMU (performance monitoring unit) をゲストに公開しないため、<not supported> を報告することがよくあります。代わりに、自分のアプリケーションの throughput と latency を測定し、debugfs の knob を 2 回の実行の切り替えに使用します。
カーネルに CONFIG_SCHED_CACHE があるか確認する
uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llcCONFIG_SCHED_CACHE=y なら、カーネルはこの機能を有効にしてビルドされています。# CONFIG_SCHED_CACHE is not set という行が表示される場合、そのバージョンにはこのオプションが存在しますが、ディストリビューション側で無効にされています。何も出力されない場合は、通常、そのカーネルがこのオプションより前のバージョンです。uname -r で確認できます。一部の最小構成のクラウドイメージには /boot/config-* ファイルがありません。その場合は zcat /proc/config.gz を確認します。ただし、これはカーネルが CONFIG_IKCONFIG_PROC を有効にしてビルドされている場合にのみ機能します。
ls 行は、機能が組み込まれている場合に llc_* の調整可能な値を出力します。CONFIG_SCHED_CACHE=y なのに何も出力されない場合は、まず sudo mount -t debugfs none /sys/kernel/debug で debugfs をマウントします。
この機能を有効にした場合と無効にした場合でワークロードを比較するには、最初に現在の値を記録します。テスト後に元へ戻す必要があるためです。
sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'ベンチマークを実行し、記録した値を書き戻してから、もう一度実行します。debugfs への書き込みは再起動後も保持されません。テスト中はその動作が適しています。
ディストリビューションのカーネルに 7.2 が搭載される時期
Mainline は、VPS が起動するカーネルそのものではありません。uname -r に表示されるバージョンはディストリビューションから提供されたものであり、mainline のリリースがサーバーに届くまでの経路はディストリビューションごとに異なります。
Fedora はサポート期間中、安定版リリースを新しい mainline カーネルにリベースします。そのため、Fedora では sudo dnf upgrade --refresh を実行して再起動するだけで完了し、通常はテナントが新しいカーネルを最初に試せる環境になります。VPS で Fedora Server を実行する際には、この更新サイクルも選択することになります。
Ubuntu は 6 か月ごとの各リリースで新しいカーネルを提供し、その後 HWE (hardware enablement) スタックを通じて以前の long term support (LTS) リリースにも提供します。2026 年 8 月時点で、Ubuntu 24.04 LTS は 2024 年 4 月の 6.8 を GA カーネルとして引き続きインストールします。一方、HWE スタックは 2025 年 8 月に 6.14 へ、2026 年 2 月に 6.17 へ移行しました。現実的な目安は次のとおりです。2026 年 8 月にリリースされた mainline カーネルが、LTS の HWE スタックに届くまでには約 1 年かかります。
apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04Debian stable はリリースのサポート期間中、1 つのカーネルを維持します。より新しいカーネルは backports で提供され、パッケージごとに利用を選択します。
echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64これらのいずれかを実行した後、再起動し、uname -r と上記の grep で確認します。新しいカーネルは稼働中に読み込めません。VPS での live kernel patching は、実行中のカーネルにある個々の関数のコードを置き換えますが、構造体のレイアウトを変更したり、debugfs のファイルを追加したりすることはできません。Cache aware scheduling はその両方を行います。mm_struct にフィールドを追加するため、新しいカーネルを起動した場合にのみ利用できます。
実際の運用では、次の 2 点も確認してください。新しいカーネルでしばらく負荷を処理するまで、古いカーネルを起動可能な状態で残します。これは VPS で起動するカーネルを固定するためです。また、/boot を監視してください。小規模な VPS では、カーネルを数回アップグレードするだけでブートパーティションが満杯になることがあります。詳細は Ubuntu で古いカーネルを整理するで説明しています。
最後に、所有範囲について現実的な点を説明します。KVM VPS では、ゲストカーネルは利用者の管理対象です。利用するカーネルを選択し、それで起動し、必要なら以前のバージョンへ戻せます。ホストカーネルはプロバイダーが管理するため、ゲスト内の設定でハイパーバイザーが使用するスケジューラーを変更することはできません。そのため、スケジューラーの配置に関するリリースノートは、テナントにとっては話の半分にすぎません。利用者が制御できるのは、ゲスト側の部分です。
このページで使用した情報源
- kernelnewbies.org の 7.2 changelog summary。2026年8月16日のリリース日と、scheduler 以外の変更を確認するために使用しました。
- lwn.net/Articles/1041668 および lwn.net/Articles/1058288 の cache aware scheduling series に関する LWN の解説。debugfs tunable、プロセス単位の preference mechanism、報告された benchmark の数値を確認するために使用しました。
- 機能を topology に基づいて有効化する "sched/cache: Introduce sched_cache_present" の patch。cache aware load balancing には NUMA node 内に複数の LLC が必要という規則を確認するために使用しました。
前のリリースについては、Linux kernel 7.1での変更点を参照してください。バージョン番号の由来については、Linux kernelの歴史年表を参照してください。
FAQ
Linux 7.2 の cache aware scheduling で VPS は高速になりますか？
通常、それだけでは高速になりません。この機能は、NUMA ノードが複数の last level cache を報告した場合にのみ有効になります。しかし、一般的な KVM ゲストではその構成が表示されないため、コードは実行されません。有効になる場合でも、ゲストは 2 段階でスケジュールされます。ゲストのカーネルが vCPU を選択し、ホストのカーネルがその vCPU スレッドを実行する物理コアを決定します。そのため、ゲスト側の cache の選択はホストによって無効化される可能性があります。ゲスト内で cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u を実行してください。すべての vCPU を対象とする 1 行の結果であれば、この機能が調整する対象はありません。
カーネルに CONFIG_SCHED_CACHE があるか確認するにはどうすればよいですか？
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) を実行してください。CONFIG_SCHED_CACHE=y は組み込みであることを示し、# CONFIG_SCHED_CACHE is not set はディストリビューションで無効化されていることを示します。出力がない場合、カーネルはこのオプションより古いものです。イメージに /boot/config-* ファイルがない場合は、zcat /proc/config.gz を試してください。これは CONFIG_IKCONFIG_PROC を有効にしてビルドされたカーネルにのみ存在します。実行時には sudo ls /sys/kernel/debug/sched/ | grep -i llc で確認できます。このコマンドは、機能が存在する場合に llc_* の調整項目を一覧表示します。
再起動せずに cache aware scheduling を無効にするにはどうすればよいですか？
許容値の調整項目に 0 を書き込みます。コマンドは sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance' です。これにより実行時に機能が無効になり、ベンチマーク用の明確な A/B 切り替えとして使用できます。ビルドによってデフォルト値が異なるため、最初に sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance で現在の値を読み取り、後で元の値を書き戻してください。debugfs に書き込んだ内容は再起動後も保持されません。cat が No such file or directory を返す場合、カーネルにはこの機能が組み込まれていないため、無効にする対象はありません。
Ubuntu または Debian が 7.2 ベースのカーネルをリリースするのはいつですか？
Fedora は安定版リリースを新しい mainline カーネルへリベースするため、通常の dnf upgrade と再起動を通じて最初に提供されます。Ubuntu は 6 か月ごとのリリースで新しいカーネルを提供し、HWE スタックを通じて以前の LTS にも取り込みます。過去の差はおよそ 1 年です。2026 年 8 月時点では、24.04 LTS の HWE スタックは 2026 年 2 月の 6.17 ですが、GA カーネルはまだ 6.8 です。Debian stable はリリース時のカーネルを 1 つ維持し、新しいカーネルを trixie-backports で提供します。これはパッケージ単位で apt install -t trixie-backports linux-image-amd64 を使ってインストールします。