logo标签列表

Ubuntu 16.04的kworker持续占用高CPU资源

16.04kernelperformancesystem
在Ubuntu 16.04电脑上，我发现kworker持续占用80%的CPU。
我生成了一个性能报告：
  • sudo apt-get install linux-tools-common linux-tools-$(uname -r)
  • 记录所有CPU上10秒钟的回溯信息：sudo perf record -g -a sleep 10
  • 使用sudo perf report查看报告。
前几个结果如下：
Samples: 47K of event 'cycles:ppp', Event count (approx.): 38282161158
  Children      Self  Command          Shared Object                  Symbol
+   77.04%     0.00%  kworker/3:3      [kernel.kallsyms]              [k] ret_from_fork
+   77.04%     0.00%  kworker/3:3      [kernel.kallsyms]              [k] kthread
+   77.04%     0.00%  kworker/3:3      [kernel.kallsyms]              [k] worker_thread
+   77.00%     0.13%  kworker/3:3      [kernel.kallsyms]              [k] process_one_work
+   76.26%     0.04%  kworker/3:3      [kernel.kallsyms]              [k] rpm_idle
+   75.98%     0.06%  kworker/3:3      [kernel.kallsyms]              [k] rpm_suspend
+   75.97%     0.03%  kworker/3:3      [kernel.kallsyms]              [k] pm_runtime_work
+   75.84%     0.03%  kworker/3:3      [kernel.kallsyms]              [k] __rpm_callback
+   75.82%     0.01%  kworker/3:3      [kernel.kallsyms]              [k] usb_runtime_idle
+   75.76%     0.00%  kworker/3:3      [kernel.kallsyms]              [k] __pm_runtime_suspend
+   75.64%     0.00%  kworker/3:3      [kernel.kallsyms]              [k] rpm_callback
+   75.61%     0.04%  kworker/3:3      [kernel.kallsyms]              [k] usb_runtime_suspend
+   75.51%     0.03%  kworker/3:3      [kernel.kallsyms]              [k] usb_suspend_both
+   73.51%     0.15%  kworker/3:3      [kernel.kallsyms]              [k] usb_control_msg
+   71.97%     0.14%  kworker/3:3      [kernel.kallsyms]              [k] usb_start_wait_urb
+   68.38%     0.05%  kworker/3:3      [kernel.kallsyms]              [k] usb_submit_urb
+   68.33%     0.30%  kworker/3:3      [kernel.kallsyms]              [k] usb_submit_urb.part.8
+   67.75%     0.82%  kworker/3:3      [kernel.kallsyms]              [k] usb_hcd_submit_urb
+   60.96%    60.41%  kworker/3:3      [kernel.kallsyms]              [k] xhci_hub_control
+   55.99%     0.12%  kworker/3:3      [kernel.kallsyms]              [k] hub_suspend
+   54.97%     0.04%  kworker/3:3      [kernel.kallsyms]              [k] set_port_feature
+   19.36%     0.01%  kworker/3:3      [kernel.kallsyms]              [k] usb_resume_interface.isra.8
+   19.35%     0.02%  kworker/3:3      [kernel.kallsyms]              [k] hub_resume
+   19.32%     0.14%  kworker/3:3      [kernel.kallsyms]              [k] hub_activate
+   18.78%     0.08%  kworker/3:3      [kernel.kallsyms]              [k] hub_ext_port_status
+   11.13%     0.00%  ksoftirqd/3      [kernel.kallsyms]              [k] ret_from_fork
+   11.13%     0.00%  ksoftirqd/3      [kernel.kallsyms]              [k] kthread
+   10.44%     0.51%  ksoftirqd/3      [kernel.kallsyms]              [k] smpboot_thread_fn

我不知道如何复现。重新启动后问题就消失了。 发生了什么事？
2个回答

我在戴尔XPS笔记本电脑和内核4.4.0-130上遇到了同样的问题。

我通过禁用内核中的动态USB电源管理来解决了这个问题。

我在我的内核引导命令行中添加了usbcore.autosuspend=-1。

GRUB_CMDLINE_LINUX_DEFAULT="<existing stuff> usbcore.autosuspend=-1"

要永久地做到这一点，打开 grub 配置文件
sudo nano /etc/default/grub
并添加上述描述的标志。

  • 接下来，你需要通过以下命令更新grub：

    sudo update-grub

  • 重启后，一切应该正常了，繁忙的CPU现在可以用来做一些有用的事情了 :)

禁用动态电源管理可能会影响电池寿命，尤其是在连接了USB设备的情况下。然而，只有少数USB设备能够处理这种模式。
谢谢-对我来说似乎有效！ - Fergie
对我来说，在Dell XPS 7390上使用Xubuntu 19.10似乎是有效的，尽管现在还为时过早，无法确定。 - vanadium
那对我来说适用于戴尔PowerEdge T40服务器，BTX（Intel Xeon E-2224G）。尽管它是一个塔式机而不是笔记本电脑，但仍然出现了kworker的100％CPU使用率。 - Alexis Wilke
1这对我在Ubuntu 20.04.1 LTS上有效，而这个问题在过去两周从未出现过。谢谢，你让我的一天变得美好！ - Louis Gagnon
我在Ubuntu Server 20.04.1 LTS上遇到了相同的问题，这个解决方案解决了我的问题。非常感谢您的解决方法！ - Logus Graphics

我曾经在戴尔笔记本电脑上遇到类似的问题。我读到说这是内核的一个bug，可以通过向/sys目录下的某个文件写入一些值来清除一些内核缓存来解决，但是我怀疑这对你可能没有帮助。

我知道无法终止kworker进程。如果我要相信Askubuntu/Unix上对同样问题的其他答案，kworker是与内核活动对应的占位符进程。

下面提出的解决方案按最明显和可能产生结果（如果尚未尝试）的顺序排列，直到较不可能。

以防万一，如果你还没有这样做，我建议你将内核更新到存储库中最新可用版本（sudo apt update）。通常需要重新启动才能看到效果。

否则，你可以尝试安装Ubuntu 18.04，它的内核版本是4.15.0-22，可能集成了修复程序。

如果你已经搜索过你的问题，你可能已经找到了与你描述相符的bug报告。你应该仔细阅读其中的评论，有时候会包含解决方案或变通方法。下面的链接似乎与你的问题非常相似，尽管有点奇怪，因为修复程序应该已经进入了Ubuntu的内核中（第18条评论）。

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1488426

在我遇到这个错误时，我没有尝试使用像cpulimit或cputool（sudo apt install cpulimit或sudo apt install cputool）这样的CPU限制应用程序。我不知道这种方法是否有机会奏效。我怀疑它能否适用于这样一个非标准的进程。
注意：每当涉及到Linux内核的问题时，您可能希望在您的问题和未来的问题中添加uname -mr的输出。
如果您发现有可行的解决方案，请写下答案。
谢谢您的回复，但是您提出的建议对我来说并不可行。
  • 由于某些驱动程序无法正常工作，无法更新内核，但这仍然可以是一个可能的修复方法。
  • 由于程序构建问题，目前无法升级到Ubuntu 18，主要需要cuda 8。
  • 限制CPU不是个好主意，因为我们需要计算资源。
  • 目前还没有找到解决办法。
如果我找到了什么东西，我会发布。 - sunapi386