18

Linux 上の同じプロセスのスレッド間のコンテキスト切り替えのコストに関する適切な経験的データはありますか (主に x86 と x86_64 が重要です)。私は、あるスレッドがユーザー空間で実行する最後の命令と、自発的または非自発的にスリープ状態になる前のサイクル数またはナノ秒数と、同じ cpu/コアでウェイクアップした後に同じプロセスの別のスレッドが実行する最初の命令について話している.

同じ CPU/コアに割り当てられた 2 つのスレッドで常に実行rdtscし、結果を volatile 変数に格納し、姉妹スレッドの対応する volatile 変数と比較する簡単なテスト プログラムを作成しました。姉妹スレッドの値の変更を初めて検出すると、違いが出力され、ループに戻ります。この方法で、Atom D510 CPU で約 8900/9600 サイクルの最小/中央値を取得しています。この手順は合理的で、数字は信頼できると思いますか?

私の目標は、最新のシステムで、接続ごとのスレッド サーバー モデルが選択型の多重化と競合するか、それを上回るかどうかを見積もることです。Xfd で IO を実行することから fd への移行Yは、複数のシステムコールではなく、あるスレッドでスリープ状態になり、別のスレッドで起動するだけであるため、理論的にはもっともらしいようですが、コンテキスト切り替えのオーバーヘッドに依存します。

4

1 に答える 1

16

(免責事項:これは質問に対する直接の回答ではありません。役立つと思われるいくつかの提案です)。

まず、取得している数値は、球場内にあるように聞こえます。ただし、割り込み/トラップのレイテンシは、同じ ISA を実装するさまざまな CPU モデル間で大きく異なる可能性があることに注意してください。スレッドが浮動小数点演算またはベクトル演算を使用している場合も、別の話です。使用していない場合、カーネルは浮動小数点またはベクトル ユニットの状態の保存/復元を回避するためです。

カーネル トレース インフラストラクチャを使用すると、より正確な数値を取得できるはずですperf sched。特に、スケジューラのレイテンシを測定および分析するように設計されています。

目標が接続ごとのスレッド サーバーをモデル化することである場合、おそらく非自発的なコンテキスト スイッチの待ち時間を測定するべきではありません。通常、そのようなサーバーでは、スレッドread()がさらにデータを待機する際にブロックされるため、コンテキスト スイッチの大部分は自発的になります。ネットワークから。したがって、より良いテストベッドには、あるスレッドが でブロックされてread()から、別のスレッドが同じスレッドから起動されるまでのレイテンシを測定することが含まれる場合があります。

高負荷下で適切に作成された多重化サーバーでは、 fd から fdXへの移行にYは、多くの場合、同じ単一のシステム呼び出しが含まれることに注意してください (サーバーは、単一の から返されたアクティブなファイル記述子のリストを反復処理するためepoll())。また、1 つのスレッドは複数のスレッドよりも少ないキャッシュ フットプリントを持つ必要があります。これは、スタックが 1 つだけであるためです。問題を解決する唯一の方法(「解決」の定義について)は、ベンチマークの銃撃戦を行うことかもしれません...

于 2011-05-11T04:17:19.057 に答える