私は完全に公正なスケジューラについてかなり多くの説明を聞きましたが、すべて1つの重要な詳細が不足しているようです。すべてが説明されている方法は、本質的に実行されている「キュー」（効率的な順序を維持するレッドブラックツリー）の要約と、各プロセスがvruntime値を更新する方法の詳細にまとめられています。主な詳細の概要はスキップし、私の質問に重要な内容に集中します。
プロセスがスケジュールされるたびに vruntime が更新され、CPU に到達した時間を反映します。これらの説明の大部分は、値が単調に増加することを示しています（「厳密に増加する」ことがより正確であっても）。オペレーティングシステムは、新しいプロセスをスケジュールすることを決定するたびに、vruntimeが最も低いプロセスを見て、実行のために送信します。
これらの説明には重要な詳細がありません。実行、実行、実行するブラウザプロセスがあるとします。数日後、そのプロセスのvruntimeは、多くの時間のCPU時間を反映して大きくなります。同じマシン（説明のために単一のCPUハードウェア）には、新しいCPUバインディングプロセスがあります。スケジューラは両方のプロセスを調べて、CPU Hogのvruntimeが0であることを確認し、それをスケジュールします。
私が見たすべてのCFS記述は、このプロセスが他のプロセスのvruntimeが減るまで実行されることを示していますが、これは本当ではありません。この場合、ブラウザプロセスは数時間または数日後にCPU使用率が追いつくまで中断されます。
ファジー要素があるか、仮想ランタイムを直接比較するよりも多くが必要ですが、このすべての説明ではこの重要な詳細をスキップしました。私は何を見逃していますか？
（また、大規模なマルチCPUシステムがプロセスグループのvruntimeをオーバーフローできることを知っている人はいますか？CPU時間は約544年を取得する必要がありますが、64プロセッサシステムは10年間動作する可能性があります.....神経書かないでください。
ベストアンサー1
したがって、一般的な CFS の説明には 2 つの事項がありません。スケジューラは vruntime が最も低いプロセスを選択して実行します。ただし、vruntime は、実際にプロセスが CPU で費やした時間を表さず、現在の実行キューで費やした時間も表しません。これは、気まぐれな数学を通して希望の意味を奇妙に構成する経験的に計算された値です。
各CPUには独自のプロセスキュー（実際にはRBツリーですがキューのように動作します）があります。各プロセスキューは、仮想ランタイムが最も小さいプロセスである「最も左の」プロセスを追跡します。合計実行時間を追跡するときにキューの仮想実行時間を計算しないでください。代わりに、プロセスの仮想ランタイムとキューの最小ランタイムの違いを考慮してください。この違いは重要な意味を持ちます。これは、対応するプロセスと一番左のプロセスの間の実行時間の差です。つまり、このプロセスが一番左のプロセスよりもCPU時間をどのくらい受け取るのかということです。
したがって、新しいプロセスがCPUキューに入ると、vruntimeはありません。一番左のプロセスと同じ値を継承するだけです。 vruntimeは今同じなので、違いは0です。これは新しいプロセスです予想される一番左のプロセスより CPU 時間が長くなります。次のコンテキスト切り替え時に新しいプロセスがスケジュールされる可能性があります。
プロセスはさまざまな理由で実行キューを残します。 IO を待つか、休止状態が実行キューを離れる一般的なトリガーです。プロセスが一時的にCPUを必要としないようにする状況では、そのプロセスはキューから削除されます。これが発生すると、休止状態プロセスのvruntimeから現在の最小vruntime（最も左側のプロセスのvruntime）を減算します。その結果、vruntime は、次の予約プロセスより CPU 時間がどれだけ多くなるかを反映します。実行キューに再参加しようとすると、キューの最小vruntimeがプロセスのvruntimeに追加され、キューの中央のどこかに入力されます。これは、前のキューを離れたときに楽しんだのとほぼ同じ場所です。
それが説明です。 vruntimeは、プロセスが現在実行キューにあるか予約可能な状態であるかにかかわらず、CPU公平性履歴の相対的な違いとして解釈できるように、賢い方法で動作します。