コンテキスト切り替え時間は純粋なオーバーヘッドであり、役に立たないことを知っているだけです。しかし、コンテキスト切り替え時間を短縮する方法を知りたいです。より多くのレジスタを使用すると、そうするのに役立ちますか?
3 に答える
あなたはオペレーティングシステムを書いていますか?コンテキスト切り替え時間は、保存/復元する必要があるレジスタに依存します。時間を節約できる 1 つの方法は、新しいプロセッサの AVX 拡張機能を使用することです。これにより、すべてのレジスタを 1 つのメモリ ブロックに保存/復元できます。
コンテキスト サイズを最小化するか、コンテキスト スイッチを回避してください。それをどのように正確に行うかは、コンテキストによって異なります (切り替えているコンテキストではなく、問題のコンテキスト、CPU、OS など)。
x86 CPU では、浮動小数点ユニットの状態が変化しない場合、その状態の不必要な保存と復元を避けることができます。これは、コンテキストの切り替え中にtask switched
ビットを 1 に設定し、新しいスレッドの最初の FPU 命令から発生する特別な CPU 例外を待機することによって行われます。CR0
それが発生すると、古いスレッドの FPU 状態を保存し、現在のスレッドの FPU 状態をロードし、CR0.TS
その FPU 命令でリセットして実行を再開します。スレッドが行き来しても例外が発生しない場合は、スレッドが FPU の作業を行っておらず、完全なコンテキスト スイッチを行っていないことを意味します。
ロックの競合を最小限に抑えるスレッド ポリシー、同期メカニズム、およびデータ構造を実装するのは、プログラマ次第です。スレッドが別のスレッドによって既に取得されているロックを取得しようとすると、非常に短い時間内にロックが解放されることを期待して数回ポーリングし、あきらめてコンテキスト スイッチを実行する以外に選択肢はほとんどありません。
この質問が Linux 管理者の観点からのものである場合、最小タイムスライス (sched_latency_ns および sched_min_granularity_ns を参照) を増やすか、プロセッサの需要が利用可能な数以下であることを確認することで、コンテキスト スイッチに費やされる時間を短縮できます。プロセッサ。予備のプロセッサがある場合、コンテキストの切り替え率は大幅に低くなります。既存のプロセッサを「切り替える」必要はなく、アイドル状態のプロセッサを使用できます。