Pthreads の Ubuntu システムでのさまざまなスケジュール アルゴリズムの影響を分析しようとしています。いくつか (1、2、4) のスレッドを作成し、それらを 1、2、または 4 個の CPU で実行させます。各スレッドは、1 つの数学演算を含む for ループです。1 つのスレッドが完了するまでに数秒かかります。
FIFO を使用して 1 つの CPU で 2 つのスレッドを開始すると、かなりの時間差で終了します (論理的には、FIFO が最初に作成されたスレッドを最初に終了します)。RR の場合、両者はより接近して終了します (場合によっては 0.5 秒の差)。これは予想通りです。ここで、各テストを 10 回実行し、測定の約 1/3 に他の測定の半分の時間がかかります。すべてのスレッドが終了するまでの時間を測定します。したがって、1 つの CPU では、2 つのスレッドが終了するのを待ちます。RR または FIFO はほとんど違いがありません。ただし、テストを複数回実行すると、2 ～ 3 回で約 6 秒、5 ～ 6 回で約 12 秒かかる場合があります。異常なのは、9秒や10秒くらいで番組が終わったことがないということです。5 から 6 の間、または 11 から 13 の間です。これらの測定は、4、2、1 CPU 上の 4、2、1 スレッドに対して行いました。FIFO と RR。優先度は 0 と 99 (リアルタイム) の両方に設定されています。CPU を使用している重いアプリケーションはありませんでした。使用されたコアでは、CPU 時間の 97% 以上が、プログラムによって生成されたスレッドに費やされました。
SCHED_OTHER を使用する場合、そのような現象はありません。
誰かがこの振る舞いについて説明を受けましたか?
コンテキスト スイッチが何回発生するかを確認するのは困難です。FIFO の場合、コンテキスト スイッチの量は 0 に近くなるはずです。RR の場合、これはかなり大きくなりますが、合計実行時間にはほとんど影響しません。SCHED_OTHER については、コンテキストの切り替えが最も多いと推測していますが、完全にはわかりません。
もう 1 つの興味深い事実は、OTHER の合計実行時間は、同じ量のスレッドと CPU を使用した FIFO の短い時間とほぼ同じであることです。そのため、FIFO は OTHER と同じくらい高速な場合もありますが、2 倍の時間がかかる場合もあります。
よろしく、
ロエル・ストームズ