新しいLinuxカーネルでは、コンテキストの切り替えが非常に遅くなります
サーバーのOSをUbuntu 10.04 LTSからUbuntu 12.04 LTSにアップグレードする予定です。残念ながら、実行可能になったスレッドを実行するための待ち時間は、2.6カーネルから3.2カーネルに大幅に増加したようです。実際、私たちが得ている待ち時間の数値は信じがたいものです。 テストについてより具体的に説明します。2つのスレッドを実行するプログラムがあります。最初のスレッドは現在の時刻（RDTSCを使用したティック単位）を取得し、1秒に1回条件変数を通知します。2番目のスレッドは、条件変数で待機し、シグナルが送られると起動します。次に、現在の時刻を取得します（RDTSCを使用したティック単位）。2番目のスレッドの時間と最初のスレッドの時間の差が計算され、コンソールに表示されます。この後、2番目のスレッドは条件変数をもう一度待機します。約2秒後、最初のスレッドによって再度シグナルが送信されます。 つまり、結果として、1秒に1回、条件変数のレイテンシ測定を介してスレッド間通信を取得します。 カーネル2.6.32では、この待ち時間は2.8〜3.5 us程度であり、これは妥当です。カーネル3.2.0では、このレイテンシは40〜100 us程度に増加しています。2つのホスト間のハードウェアの違いを除外しました。それらは同一のハードウェアで動作します（ハイパースレッディング、スピードステップ、およびすべてのC状態がオフの状態で3.6 GHzで動作するデュアルソケットX5687 {Westmere-EP}プロセッサー）。テストアプリは、同じソケットの独立した物理コアで実行するようにスレッドのアフィニティを変更します（つまり、最初のスレッドはCore 0で実行され、2番目のスレッドはCore 1で実行されます）。したがって、スレッドのバウンスはありません。コアまたはソケット間のバウンス/通信。 2つのホストの唯一の違いは、1つはカーネル2.6.32-28（高速コンテキストスイッチボックス）でUbuntu 10.04 LTSを実行しており、もう1つはカーネル3.2.0-23（低速コンテキスト）で最新のUbuntu 12.04 LTSを実行していることです。スイッチボックス）。BIOS設定とハードウェアはすべて同じです。 スレッドの実行をスケジュールするのにかかる時間のこのとんでもない速度低下を説明できるカーネルの変更はありましたか？ 更新： ホストとLinuxビルドでテストを実行したい場合は、閲覧用のコードをペーストビンに投稿しました。コンパイル： g++ -O3 -o test_latency test_latency.cpp -lpthread 実行（少なくともデュアルコアボックスがあると仮定）： ./test_latency 0 1 # Thread 1 on Core 0 and Thread 2 on Core 1 更新2：カーネルパラメータの検索、カーネルの変更に関する投稿、および個人的な調査の結果、問題が何であるかがわかり、この質問に対する回答として解決策を投稿しました。