# ネットワークワークロードのCPUスケジューリング ## 定義 ネットワークワークロードの CPU スケジューリングは、一般的な CPU 時間の均等配分だけでなく、パケット、要求・応答、接続、in-flight 数、キャッシュ局所性を考慮してネットワーク処理の進捗と公平性を決める設計問題である。 Linux の通常の CPU スケジューラはスレッドの virtual runtime を公平性の代理にするが、softIRQ の誤帰属やキャッシュ待ちによって、同じネットワーク処理を行うスレッドの実際の進捗と runtime がずれる。(Source: [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) ## 設計軸 - **計上対象**: softIRQ 時間をどのスレッドへ帰属させるか。 - **公平性単位**: CPU runtime、パケット数、要求・応答数のどれを進捗の代理にするか。 - **局所性**: 接続、NIC キュー、CPU コア、NUMA ノードの対応をどう保つか。 - **到着制御**: NIC の割り込み閾値を観測履歴で調整するか、受信側が予測可能性を与えるか。 - **並列度**: 接続数を増やすか、少数接続の in-flight 要求を増やしてパケット集約を維持するか。 ## 横断的知見 - **CPU サイクルの主因とテールレイテンシの主因は同じとは限らない**: 100 Gbps Linux の長フローでは受信側データコピーが CPU サイクルの約 49%を占め、フロー競合時にはスケジューリングも増える。一方、64 バイト RPC のテールでは、`rx_sched` がパケット処理より桁違いに大きい。高帯域の平均コスト分析と短 RPC のテール分析は、同じホストスタックでも異なる公平性単位を要求する。(Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) - **ネットワークスタックをユーザー空間へ移すことと、ネットワーク進捗を公平に計上することは別問題である**: mTCP はコアローカル状態とイベントバッチ化でカーネルの共有・切り替えコストを避けるが、Linux も少数接続と十分な in-flight 要求を選べば 1 コアあたり 1.28 million IOPS、P99.9 90 マイクロ秒に到達する。ユーザー空間スタックとの比較では、スタックの場所だけでなく接続並列度、バッチ、CPU 競合条件を揃える必要がある。(Source: [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) - **コア局所性はスケジューラの外側でも実現できるが、ポーリングとアプリケーション停止の責任を引き受ける**: LUNAはNICマルチキューと共有なしr2cでTCP処理とアプリケーション処理を同じコアへ寄せ、コンテキストスイッチとキャッシュ競合を避ける。一方、r2cがアプリケーションレベルで停止するとNICキュー溢れとTCPタイムアウトを招きうるため、CPUスケジューラの公平性問題を消すのではなく、責任境界をアプリケーションとNICキューへ移している。(Source: [[@2023__USENIX ATC__Deploying User-space TCP at Cloud Scale with LUNA]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) - **割り込み調整は独立した NIC チューニングではなく、スケジューラの公平性と結合した制御ループである**: DIM は割り込みを減らしてスループットを高めるが、バースト性到着では `rx_irq` と `rx_sched` のどちらかを悪化させうる。予測可能な in-flight 数を利用する AutoDIM は、トラフィックの到着形状を設計できる受信側主導プロトコルとの協調を示す。(Source: [[@2026__SIGCOMM__Understanding Host Network Stack Latency]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]]) - **局所性の確保と公平な負荷配分は別の問題である**: Fastsocket は接続を一つのコアへ固定し、共有ロックとキャッシュバウンスを除く一方、固定先のコアが高負荷になると「ホットコア」が実効容量と SLA を制限する。論文は最頻使用コアの CPU 使用率を実効容量の基準に置き、後続研究は要求数・softIRQ・割り込み調整を公平性の単位として扱う。(Source: [[@2016__ASPLOS__Scalable Kernel TCP Design and Implementation for Short-Lived Connections]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) ## 未解決の問い - CPU runtime、パケット数、要求数、キャッシュミスを組み合わせた公平性単位を、異種 RPC とストリーム混在でどう定義するか。 - `sched_ext` や eBPF のプログラマブルスケジューラへ、ネットワーク要求の完了数を安全かつ低オーバーヘッドに渡せるか。 - 受信側主導トランスポート、DIM、CPU スケジューラを一つのフィードバック制御として設計したとき、輻輳制御との安定性をどう保証するか。 - NUMA 配置、キャッシュ分離、受信側ゼロコピーと要求数ベース公平性を同時に適用した場合、どの資源が次のボトルネックになるか。 - マルチテナント環境で、ある接続のパケット到着が他接続の virtual runtime やキャッシュ状態を歪める干渉をどう分離・観測するか。 - LUNAの共有なしr2c、LinuxのPCSched、Fastsocketの接続局所化を、CPU効率だけでなくアプリケーション停止時のパケット損失と復旧時間を含めて比較できるか。 ## 関連 - [[ホストネットワークスタック性能]] — データコピー、キャッシュ、NUMA、フロー競合を含むホスト側の性能領域。 - [[ネットワーク割り込み合体とCPUスケーリング]] — NAPI、DIM、RSS/RFS と CPU へのパケット分散。 - [[ユーザーレベルTCPスタック]] — コアローカル状態とイベントバッチ化を用いるユーザー空間実装。 - [[カーネルバイパスネットワーキング]] — カーネルスタックを迂回する設計と、カーネル内最適化との境界。 - [[レイテンシ分析]] — エンドツーエンドレイテンシをスタック区間へ分解する方法論。 - [[Linux]] / [[eBPF]] / [[sched_ext]] - [[TCP接続局所性]] — 接続状態とネットワーク処理を同じ CPU コアへ固定する設計。 ## 出典 - [[@2026__SIGCOMM__Understanding Host Network Stack Latency]] - [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]] - [[@2014__NSDI__mTCP - a Highly Scalable User-level TCP Stack for Multicore Systems]]