# OSノブチューニング ## 定義 **OSノブチューニング**は、スケジューラ・電力管理(DVFS/C-state)・メモリ・I/O(NAPI ポーリング等)といった、オペレーティングシステムが公開する実行時制御ノブを、稼働中のアプリケーション性能を改善する目的で調整するプロセスを指す。[[@2026__arXiv__TuxBot - Semantic-Aware Online OS Tuning with Large Language Models]] はこれを、リクエスト単位でインラインに動くカーネル高速パス制御器(CPU スケジューラ本体・パケットスケジューラ・輻輳制御等)とは区別し、数秒〜数分の時間スケールで定常状態の性能を最適化する「out of band」なオンライン制御ループとして定義する。Linux は現在 1,200 を超えるチューナブルノブを公開しており、その最適値はワークロード・ハードウェア・現在の稼働条件に依存する。 ## 横断的知見 - **OS ノブは独立変数ではなく結合したポリシーを構成する**: カーネルはスケジューラ・CPU 電力・メモリ・I/O の設定を組み合わせて 1 つの実行時ポリシーとして解釈するため、各ノブを独立な数値範囲を持つ変数として扱う古典的チューナー(ベイズ最適化の MLOS、Q-Learning/DQN 等)は、数値的には妥当だがワークロードには意味を成さない設定や、内部的に矛盾する設定(例: minperfpct>maxperfpct)を繰り返し探索してしまう([[@2026__arXiv__TuxBot - Semantic-Aware Online OS Tuning with Large Language Models]] §2)。 - **アプリケーションメトリクスの不在は単一プロキシで代替できない**: IPC やキャッシュミスのような低レベルプロキシは、スケジューラの挙動・メモリ圧迫・I/O 活動によって同じ値が全く異なる状態を反映しうるため、単一の代替報酬としては信頼できない。PostgreSQL/Wikipedia では IPC/キャッシュミスへの置き換えで p99 が最大 2 倍悪化する。 - **制御サーフェスの拡大は探索空間の拡大以上の問題を生む**: ノブ数が増えるほどノブ間の相互作用が組合せ的に増加し、キューの蓄積やキャッシュの乱れ、writeback 圧力などの回復困難な状態に陥る経路が増える。PostgreSQL/TPC-C ではチューニング対象を 1 → 32 ノブに増やすだけで p99 が 50% 悪化する。 - **LLM をノブ・テレメトリの意味論的推論器として使うアプローチが有効**: ノブ名・サブシステム構造・ドキュメント・テレメトリ・履歴を文脈として与えられた LLM は、候補設定を孤立した数値ではなく「スケジューラ/電力/メモリ/I/O ポリシー」として解釈でき、矛盾する組み合わせの事前棄却・joint telemetry signature からのアプリケーション進捗推論・大きな制御サーフェスでの探索の絞り込みに使える([[@2026__arXiv__TuxBot - Semantic-Aware Online OS Tuning with Large Language Models]] §3)。 - **オンライン推論のコスト・遅延・安全性の制約は dual-loop + 型付き検証で緩和できる**: 低遅延の Instant ループ(1〜5 秒)と低頻度の Reasoning ループ(数十秒)を分離することで、強力だが遅いモデルをすべての制御ステップに置く必要がなくなる。同時に、モデル出力を「提案」に留め、型付き Parameter Validator を経てからのみカーネル/sysctl に書き込む設計が、LLM の自由形式シェルアクセスがもたらす致命的な状態変化(CPU offlining の誤操作等)を防ぐ。 - **セッション横断メモリは制約ではなくソフトなウォームスタートとして機能する**: 過去実行の埋め込み検索(k=3 程度が最適、k=1 は単一の弱い一致に引きずられて脆い)から合成した事前分布は、未見ワークロードへの転移にも有効だが、実測値と新規の行動-応答履歴によって上書きされるべきソフトなヒントとして扱う必要がある。 - **データベースノブチューニングと同型の失敗構造を共有する**: OS ノブと DB ノブはいずれも「多数の相互作用するパラメータ」「単一プロキシ報酬の不安定性」という共通の課題を持ち、LLM ベースの解決アプローチ(DB-BERT・GPTuner・λ-Tune が構造化・刈り込み・誘導に LLM を使うのと同様、TuxBot はオンライン制御ループに意味論的推論を持ち込む)も並行して発展している([[データベースノブチューニング]] / [[NLPベースDBチューニング]] 参照)。ただし OS チューニングはオフライン事前処理では済まず、稼働中のサービスを止めずに意思決定する必要がある点でオンライン制約がより厳しい。 ## 未解決の問い - LLM ベースのオンライン OS チューニングは、単一ホスト・単一アプリケーションを超えて、co-located な複数アプリケーション間の干渉・多目的報酬・cgroups 等でのパーティション化された制御領域にどう拡張できるか([[@2026__arXiv__TuxBot - Semantic-Aware Online OS Tuning with Large Language Models]] §4.5 が今後の課題として明示)。 - 永続的なワークロード/プラットフォームシフト(ドリフト)を、短命なノイズと区別してオンラインで検知し、いつセッションを再開すべきかを判断する一般的な手法は何か。 - モデルバックエンドへの依存度はどの程度か。Gemini 2.5 Flash 以外のバックエンド(Gemini 3 Flash・Kimi K2)では品質・コスト・安定性のいずれかが劣化することが TuxBot で観測されており、この依存を減らす設計(例: バックエンド非依存の検証層の強化)は可能か。 - 短命ジョブや急変するバースト性ワークロード、サブ秒の反応を要する過負荷エピソードなど、定常状態チューニングの前提が崩れる領域に対して、同様の意味論的推論をどう適用できるか。