Question

在我使用内核3.2新安装的系统上，我看到一个不断消耗CPU的kworker线程。我想找出内核/模块的哪个部分创建了这个工作队列。

如何跟踪名为''kworker / 0：3的kworker-thread到内核空间的原点？

我试着查看/ sys / kernel / debug / tracing / events / workqueue，但是无法弄明白。

Answer 1

（在我看来这是偏离主题的，但这是我在answer上发布的unix.stackexchange.com。）

我发现this thread on lkml可以回答你的问题。（看起来连Linus本人都对如何找出这些线程的起源感到困惑。）

基本上，有两种方法可以做到这一点：

$ 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。

Answer 2

所以，过了一段时间我找到了解决方案。实际上Anthon是对的，它是发送中断的ACPI子系统。在我的系统上，我禁用了以下中断，并且kworker-thread被平静下来。

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

但是直到现在还没有确定来自gpe08和gpe1B的假IRQ是什么。

Answer 3

kworker /看门狗在没有电缆供电时会定期造成高负荷 - 解决方法

只有当笔记本电脑由电缆供电时，是否有kworker（导致kernel_thread_helper + 0x6 / 0x10？）线程1每5秒钟触发100％的cpu 1秒钟。电池电量没问题。电池是否充满电并不重要。

它或多或少出现了，所以我猜最近的Ubuntu更新是原因（现在是3.2.0-55-generic-pae）。

正在寻找半天，试图弄清楚wft根本原因是什么并且努力尝试禁用所有acpi中断，这无关紧要。

最后在/ etc / defaults / grub中添加GRUB_CMDLINE_LINUX_DEFAULT =“acpi = off”。

正如我现在发现的那样，我添加了这些确切的特殊unicode引号，这可能解释了与“安静的启动”（默认引号）的不兼容性，这让我感到困惑。我不得不考虑一些更多的grub问题（启动菜单没有显示，但我尝试，默认条目配置未使用...）所以我将暂时离开测试。

PS：一周后，问题又回来了（没有重启，只有暂停）。使用usb鼠标可能存在相关性。断电/上电有帮助（重启没有）。抛弃所有grub选项。我希望这个问题能在某个时候出现。

PPS：花了一些时间（半年），但是从公羊恢复后又回来了。没有最近的更新，只是插拔电源，就像我经常做的那样。没有插入/拔出USB设备。在暂停期间有一个图腾运行（但没有播放）。插上电源线时断电/上电不帮助，拔掉电源线时断电/上电。

Answer 4

针对此类问题的另一种解决方案（我已经在不同的thread上发布过，也许您可以找到解决问题的其他解决方案）是使用 perf工具（默认情况下并非始终启用此功能，您可能需要在设备上install perf。）

步骤1：设置性能以记录工作队列事件：

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)正在执行该工作。

摘要：现在回到您的问题，我们看到kworker/0:3任务已请求turtle来运行pm_runtime_work函数。因此，让我们回到代码，看看这个pm_runtime_work函数的作用！也许在这里，我们将设法了解为什么它消耗了如此多的CPU。

Answer 5

kworker是一个处理工作队列的内核线程。这个线程是在linux / kernel / workqueue.c文件中创建的。

kworker线程的起源

5 个答案: