19

カーネル3.2を使用して新しくインストールしたシステムでは、CPUを常に消費しているkworkerスレッドが表示されます。カーネル/モジュールのどの部分がこのワークキューを作成したかを知りたいのですが。

たとえば''kworker / 0：3という名前のkworkerスレッドをカーネル空間の原点まで追跡するにはどうすればよいですか？

/ sys / kernel / debug / traceing / events / workqueueを調べようとしましたが、理解できませんでした。

4

5 に答える 5

22

（私にはこれはここではかなり話題から外れているようですが、ここに私がunix.stackexchange.comに投稿した答えがあります。）

私はあなたの質問に少し答えるlkmlでこのスレッドを見つけました。（Linus自身でさえ、それらのスレッドの起源を見つける方法について戸惑っていたようです。）

基本的に、これを行うには2つの方法があります。

$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)

このためには、カーネルでftraceをコンパイルする必要があります。

これにより、スレッドがすべて実行していることが出力され、複数の小さなジョブをトレースするのに役立ちます。

cat /proc/THE_OFFENDING_KWORKER/stack

これにより、多くの作業を行う単一スレッドのスタックが出力されます。これにより、この特定のスレッドがCPUを占有した原因を特定できる場合があります（たとえば）。THE_OFFENDING_KWORKERプロセスリスト内のkworkerのpidです。

于 2013-02-19T04:07:56.977 に答える
9

それで、しばらくして私は解決策を見つけました。実際、Anthonは正しいです。割り込みを送信するのはACPIサブシステムです。私のシステムでは、次の割り込みを無効にしたところ、 kworker -threadが落ち着きました。

echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08

ただし、これまで、偽のIRQが何から来ているのかを特定していませんでしgpe08たgpe1B。

于 2012-10-24T14:31:22.253 に答える
3

kworker/ウォッチドッグがケーブル電源を使用していないときに定期的に高負荷を引き起こす-回避策

ラップトップがケーブルで電力を供給されている場合にのみ、kworker（kernel_thread_helper + 0x6 / 0x10？）スレッド1が5秒ごとに1秒間CPUの100％にスパイクしていました。バッテリー電源に問題はありません。バッテリーが完全に充電されていても問題ありませんでした。

それは多かれ少なかれ思いがけないことだったので、最近のUbuntuアップデートが原因だったと思います（現在は3.2.0-55-generic-pae）。

半日を探していましたが、根本的な原因を突き止めようとして、すべてのacpi割り込みを無効にしようとしてしまいましたが、これは問題ではありませんでした。

GRUB_CMDLINE_LINUX_DEFAULT =” acpi = off”を/ etc / defaults / grubに追加すると、最終的に役立ちました。

私が今発見したように、私はこれらの正確な特別なユニコード引用符を追加しました。これは、私を困惑させた「静かなスプラッシュ」（デフォルトの引用符付き）との非互換性を説明するかもしれません。私はさらにいくつかのgrubの問題を調査する必要があります（ブートメニューが表示されないのですが、デフォルトのエントリ構成は使用されていません...）ので、後でそのテストを残します。

PS：1週間後、問題が再発しました（再起動せず、途中で一時停止するだけです）。USBマウスの使用には相関関係がある可能性があります。パワーダウン/パワーアップが役立ちました（再起動はしませんでした）。すべてのグラブオプションを捨てました。いつかまた問題が発生することを期待しています。

PPS：しばらく（半年）かかりましたが、RAMからの再開後に再び戻ってきました。最近の更新はありません。私がよく行うように、電源を抜き差しするだけです。USBデバイスが接続/切断されていません。サスペンド中にトーテムが実行されていました（ただし、何も再生されていません）。電源ケーブルを差し込んだ状態での電源切断/電源投入は役に立ちませんでしたが、電源ケーブルを抜いた状態での電源切断/電源投入は役に立ちました。

于 2013-10-27T14:18:29.433 に答える
2

これらの種類の問題に対する追加の解決策（私は少し前に別のスレッドに投稿しましたが、おそらくあなたはあなたの問題に対する追加の解決策を見つけることができます）はperfツールを使用することです （これはデフォルトで常に有効になっているわけではなく、あなたはデバイスにperfをインストールする必要があり ます）。

ステップ1：ワークキューイベントを記録するようにperfを設定します。

perf record -e 'workqueue:*' -ag -T

ステップ2：イベントをキャッチする必要があると思われる限り実行します（このイベントが十分に頻繁に発生する場合は10秒で問題ありませんが、デバイスに残っている空き容量に応じて、より長く実行させることができます）次に、で停止しCtrl + Cます。

ステップ3：キャプチャされたイベントを出力します（Linuxバージョン<4.1では、-Fではなく-fである必要があると思います）：

perf script -F comm,pid,tid,time,event,trace

これにより、次のように表示されます。 

      task-name    pid/tid     timestamp    event 
------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
    turtle        9201/9201   1473.339166:  workqueue:workqueue_queue_work:    work struct=0xef20d4c4 function=pm_runtime_work workqueue=0xef1cb600 req_cpu=8 cpu=1
    turtle        9201/9201   1473.339176:  workqueue:workqueue_activate_work: work struct 0xef20d4c4
    kworker/0:3  24223/24223  1473.339221:  workqueue:workqueue_execute_start: work struct 0xef20d4c4: function pm_runtime_work
    kworker/0:3  24223/24223  1473.339248:  workqueue:workqueue_execute_end:   work struct 0xef20d4c4

ステップ4：上記の表を分析する：

最初の行で、という名前のタスクturtle (pid 9201)が作業をワークキューにプッシュしpm_runtime_workています。kworker/0:3 (pid 24223)3行目では、がその作業を実行していることがわかります 。

要約：質問に戻ると、関数を実行するようにタスクからkworker/0:3要求されていることがわかります。それでは、コードに戻って、この関数が何をするかを見てみましょう ！たぶんここで、なぜそれがそれほど多くのCPUを消費するのかを理解することができます。turtlepm_runtime_workpm_runtime_work

于 2020-05-28T09:00:26.657 に答える
-4

kworkerは、ワークキューを処理するカーネルスレッドです。このスレッドは、ファイルlinux / kernel/workqueue.cファイルに作成されます。

于 2012-06-01T10:48:53.693 に答える