Linux kworker 线程的起源
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10846747/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Origin of a kworker-thread
提问by Patrick B.
On my newly installed system using kernel 3.2 I see a kworker-thread which is constantly consuming CPU. I'd like to find out which part of kernel/module has created this workqueue.
在我使用内核 3.2 的新安装系统上，我看到一个不断消耗 CPU 的 kworker-thread。我想找出内核/模块的哪一部分创建了这个工作队列。
How to track a kworker-thread named for example ''kworker/0:3 to its origin in kernel-space?
如何跟踪名为“kworker/0:3”的 kworker 线程到其在内核空间中的起源？
I tried to look into /sys/kernel/debug/tracing/events/workqueue, but wasn't able to figure it out.
我试图查看 /sys/kernel/debug/tracing/events/workqueue，但无法弄清楚。
采纳答案by anarcat
(Seems to me this is rather off topic here, but here's the answerI posted on unix.stackexchange.com.)
（在我看来，这与这里无关，但这是我在unix.stackexchange.com 上发布的答案。）
I found this thread on lkmlthat answers your question a little. (It seems even Linus himself was puzzled as to how to find out the origin of those threads.)
我在 lkml 上找到了这个线程，可以稍微回答你的问题。（似乎连 Linus 本人都对如何找出这些线程的起源感到困惑。）
Basically, there are two ways of doing this:
基本上，有两种方法可以做到这一点：
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)
For this you will need ftraceto be compiled in your kernel.
为此，您需要在内核中编译ftrace。
This will output what threads are all doing, and is useful for tracing multiple small jobs.
这将输出线程都在做什么，并且对于跟踪多个小作业很有用。
cat /proc/THE_OFFENDING_KWORKER/stack
This will output the stack of a single thread doing a lot of work. It may allow you to find out what caused this specific thread to hog the CPU (for example). THE_OFFENDING_KWORKERis the pid of the kworker in the process list.
这将输出做大量工作的单个线程的堆栈。它可以让您找出导致此特定线程占用 CPU 的原因（例如）。THE_OFFENDING_KWORKER是进程列表中 kworker 的 pid。
回答by mohanreddykv
kworker is a kernel thread which processes workqueues.This thread is created in the file linux/kernel/workqueue.c file.
kworker 是处理工作队列的内核线程。该线程创建在文件 linux/kernel/workqueue.c 文件中。
回答by Patrick B.
So, after some time I found the solution. In fact Anthon is right, it is the ACPI-subsystem which sends interrupts. On mysystem I disabled the following interrupts and the kworker-thread is calmed down.
所以，过了一段时间我找到了解决方案。事实上，Anthon 是对的，它是发送中断的 ACPI 子系统。在我的系统上，我禁用了以下中断并且 kworker-thread 平静下来。
echo disable > /sys/firmware/acpi/interrupts/gpe1B
echo disable > /sys/firmware/acpi/interrupts/gpe08
However until now haven't identified what the bogus IRQs coming from gpe08and gpe1B.
但是直到现在还没有确定虚假的 IRQ 来自gpe08和gpe1B.
回答by axm
kworker / watchdog causing high load regularly when not on cable power - workaround
kworker / watchdog 在不使用电缆电源时会定期导致高负载 - 解决方法
Had kworker (cause kernel_thread_helper+0x6/0x10 ?) thread 1 spiking to 100% of a cpu for 1 second every 5 seconds only if laptop powered by cable. No problems on battery power. Did not matter if battery fully charged.
仅当笔记本电脑由电缆供电时，kworker（导致 kernel_thread_helper+0x6/0x10 ？）线程 1 会每 5 秒将 1 线程尖峰到 CPU 的 100% 1 秒。电池电量没有问题。电池是否充满电并不重要。
It more or less came out of the blue, so I guess the recent Ubuntu update was the cause (3.2.0-55-generic-pae now).
它或多或少是突然出现的，所以我猜最近的 Ubuntu 更新是原因（现在是 3.2.0-55-generic-pae）。
Was looking for half a day, trying to figure out wft the root cause is and endet up trying to disable all acpi interrupts, which did not matter.
找了半天，试图找出根本原因是，最终试图禁用所有 acpi 中断，这无关紧要。
Adding GRUB_CMDLINE_LINUX_DEFAULT=”acpi=off” to /etc/defaults/grub helped in the end.
将 GRUB_CMDLINE_LINUX_DEFAULT="acpi=off" 添加到 /etc/defaults/grub 最终有所帮助。
As I discovered right now I added it with these exact special unicode quotes, which might explain the incompatibility with "quiet splash" (with default quotes) which puzzled me. I have to look into some more grub issues (boot menu not being displayed however I try, default entry config not used ...) so I will leave that testing for later.
正如我现在发现的那样，我用这些确切的特殊 unicode 引号添加了它，这可能解释了与“quiet splash”（带有默认引号）的不兼容，这让我感到困惑。我必须查看更多 grub 问题（但我尝试未显示启动菜单，未使用默认条目配置......）所以我将把该测试留待以后进行。
PS: a week later, the problem is back (without restart, only suspend in between). There might be a correlation to using an usb mouse. Power down/power up helped (restart did not). Threw all grub options away. I am expecting the problem to show up again sometime.
PS：一周后，问题又回来了（没有重启，只是中间暂停）。可能与使用 USB 鼠标有关。断电/通电有帮助（重启没有）。扔掉所有 grub 选项。我期待这个问题在某个时候再次出现。
PPS: Took some time (half a year), but it is back again after a resume from ram. No recent updates, just plugging/unplugging power, as I often do. No USB devices plugged/unplugged. Had a totem running (but nothing playing) during suspend. Power down/power up with power cable plugged did nothelp, power down/power up with power cable unplugged did.
PPS：花了一些时间（半年），但在从 ram 恢复后又回来了。没有最近的更新，只是插上/拔下电源，就像我经常做的那样。没有插入/拔出 USB 设备。在暂停期间有一个图腾在运行（但没有播放）。插入电源线断电/通电没有帮助，拔掉电源线断电/通电有帮助。
回答by J.M.
An additional solution (that I've already posted in different threadnot a while ago and maybe you can find there additional solutions to your problem) for these kinds of problems is to use the perf tool?(It's not always?enabled by default and you may need to install perf?on your device).
对于这些类型的问题，另一个解决方案（我不久前已经在不同的线程中发布过，也许您可以找到解决问题的其他解决方案）是使用perf 工具？（它并不总是？默认情况下启用并且您可能需要在您的设备上安装 perf？）。
Step 1:Set perf to record workqueue events:
第 1 步：设置 perf 以记录工作队列事件：
perf record -e 'workqueue:*' -ag -T
Step 2:Run it as long as you think you need to catch the event (10 seconds should be ok if this event is frequent enough, but you can let it run longer, depending on the available free space you?have left on your device) and then stop it with Ctrl?+ C.
第 2 步：只要您认为需要捕获事件，就运行它（如果此事件足够频繁，10 秒应该没问题，但您可以让它运行更长时间，具体取决于您在设备上留下的可用空间） ) 然后用 停止它Ctrl?+ C。
Step 3:Print the captured events (on?Linux versions < 4.1 I think it should be -f and not -F):
第 3 步：打印捕获的事件（在 Linux 版本 < 4.1 我认为应该是 -f 而不是 -F）：
perf script -F comm,pid,tid,time,event,trace
This will display something like this:?
这将显示如下内容：?
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
Step 4:Analyzing the table above:
第四步：分析上表：
In the first row, a task named turtle (pid 9201)is pushing the work pm_runtime_workto the workqueue.
In the third row, we can see that the?kworker/0:3 (pid 24223)is executing that work.
在第一行，一个名为的任务turtle (pid 9201)正在将工作推pm_runtime_work送到工作队列。在第三行，我们可以看到？kworker/0:3 (pid 24223)正在执行这项工作。
Summary:Now back to your questions, we see that kworker/0:3has been requested by turtletask to run the pm_runtime_workfunction.
So let's go back to the code and see what this?pm_runtime_workfunction does! Maybe here we'll manage to understand why it consumes so much CPU.
总结：现在回到你的问题，我们看到任务kworker/0:3已经请求turtle运行该pm_runtime_work函数。那么让我们回到代码，看看这是什么？pm_runtime_work功能呢！也许在这里我们会设法理解为什么它会消耗如此多的 CPU。
