2

今日、私は非常に奇妙な問題を見つけました。Redhat Enterprise Linux 6 を実行し、CPU は Intel E31275 (4 コア、8 スレッド) でした。1 つのカーネル スレッド (my_thread と呼んでいます) が正しく動作しないことがわかりました。「ps」コマンドを使用すると、my_thread のステータスが常に実行中であることがわかりました。

ps ax
5545 ?        R      3:14 [my_thread]
15774 ttyS0    Ss     0:00 -bash
...

しかし、その実行時間は常に 3:14 でした。実行中だったのに、合計時間が増えなかったのはなぜですか? proc ファイル /proc/5545/sched から、このスレッドのウェイクアップ数 (se.nr_wakeups) を含むすべての統計も常に同じであることがわかりました。

/proc/5545/stack から、このスレッドがこの関数を呼び出し、返されないことがわかりました。

interruptible_sleep_on_timeout(&q, 3*HZ);

理論的には、この関数は、他のスレッドがスレッドを起こしていない場合、3 秒ごとに戻ります。関数が戻るたびに、/proc/5545/sched の se.nr_wakeups が 1 ずつ増加します。しかし、スレッドに問題があることがわかった後は、これは発生しませんでした。

誰にもいくつかのアイデアがありますか？interruptible_sleep_on_timeout() が戻らない可能性はありますか?

更新: このスレッドに CPU アフィニティを設定すると、問題は発生しないことがわかりました。専用のコアに固定すれば、すべて問題ありません。SMP スケジューリングに問題はありますか?

再更新: BIOS でハイパースレッドを無効にしてから、今までそのような問題は見られませんでした。

4

1 に答える 1

4

まず、R はスレッドが実行状態ではなく、実行可能であることを示します。つまり、実行中という意味ではなく、スケジューラーが実行のために選択できる状態にあることを意味します。両者には大きな違いがあります。

同様の意味で interruptible_sleep_on_timeout(&q, 3*HZ); は、3 jiffy 後にスレッドを実行しませんが、3 jiffy 後に実行できるようにします。実際、「ps」で実行可能として表示されるため、実際にタイムアウトが発生した可能性があります。

問題のカーネルスレッドについて何も言わなかったので、それがあなた自身のコードにあるのか、標準のカーネルコードにあるのかさえわからないので、詳細に答えることができません.

あなたが説明した状況の考えられる理由の 1 つは、他のスレッド (ユーザーまたはカーネル) がスレッドよりも優先度が高いため、スケジューラが実行のためにそれを選択しないことです。そうである場合、それはおそらくリアルタイム優先度 (SCHED_FIFO または SCHED_RR) で実行されているスレッドではありません。

于 2011-10-21T14:43:23.307 に答える