クラスでは、プリエンプションなど、スケジューリングで使用されるさまざまなアルゴリズムについて学習していました。コンテキストを切り替える際のオーバーヘッドが懸念事項であるかどうかを誰かが尋ねたところ、教授はそれは常に無視できると述べました。これは本当ですか？ウィキペディアによると、コンテキスト切り替えが発生した場合、「プロセスの状態には、プロセスが使用している可能性のあるすべてのレジスタが含まれます...さらに、必要になる可能性のあるその他のオペレーティングシステム固有のデータが含まれます」したがって、基本的にすべてをメモリに保存する必要があります。私は無視できるとは思いませんか？
コンテキストの切り替えにかかる時間を考慮に入れるアルゴリズム/実装はありますか? たとえば、10 ミリ秒のタスクが実行されているが、8 ミリ秒かかる新しいタスクがキューに入った場合、余分なコンテキストが 10 ミリ秒に戻るため、スケジューラーは「それを忘れてください」と言うでしょうか?
無視できませんが、それほどでもありません。ユーザーレジスター、確かに、プロセスの変更とスレッドの変更が発生した場合は、おそらくより多くのセグメント/保護レジスター。スレッド スタックは既にメモリ内にあり、保存する必要はありません。I/O でスレッドの準備が整った場合、実際のコンテキスト変更はおそらくドライバー コードの実行によって処理されます。
10/8ms...
プロセス内のほとんどのコンテキスト切り替えは、それよりもはるかに高速です! プロセス内のスレッドの場合、多くの場合、uS が低く、キャッシュのフラッシュが必要な場合に新しいスレッドが実行されると、オーバーヘッドが増える可能性があります。新しく実行中のスレッドが別のプロセスに属している場合は、より多くのオーバーヘッドが発生します。保存するレジスタが増え、キャッシュなどの可能性が高くなります。さらにオーバーヘッドが発生します。コンテキスト スイッチには、シェデュラーを実行しているスレッドよりも別のコアでスレッドを停止することが含まれます。 /dispatcher 他のコアを中断する必要があるためです。
最悪の場合 - 上記のすべてに加えて、すぐにページ フォールトが発生します。これは、新しいスレッドが長時間実行されていないため、コード/スタック/その他のページ アウトが発生したためです。幸いなことに、めったに起こりません。
その 8 ミリ秒のスレッドがビデオ ストリーミング アプリの優先度の高いレンダリング スレッドである場合、遅延が発生してジッターが発生することは望ましくありません。