kcompacd0 在 VMware Workstation 16 中使用 100% CPU

Question

与 redhat bugzilla - kcompacd0 using 100% cpu中发布的相同，已关闭INSUFFICIENT_DATA.

\n

也与

\n

\n
• Linux 主机上的 VMware 导致定期冻结
\n
• Arch Linux 从 khugepaged 变得无响应
\n

\n

重新打开，因为那里的解决方案对我不起作用。

\n

这是我的情况：

\n

\n
• Ubuntu 21.10主机和 Windows 10 Enterprise 客户端，使用 VMware Workstation 16 v 16.2.0 build-18760230
\n
• 我没有做任何花哨或重负载的事情，就在常规使用 Windows 10（轻负载）一天之后，事情开始变得疯狂。
\n
• 该进程kcompactd0不断地在一个核心上使用 100% cpu，并vmware-vmx在八个核心上使用 100% cpu。\n
\n
• 当它发生时，它通常会持续几分钟。然后一两分钟后再次启动。
\n
• “kcompactd0 仅在 drop_caches 时消失。当它达到 100% 时，vmware 虚拟机来宾完全无响应（windows 10 ltsc vm）”因此我只尝试了 drop_caches 一次，并确认了该行为。
\n

\n

根据上游要求，以下是更多信息：

\n

$ lsb_release -a\nNo LSB modules are available.\nDistributor ID: Ubuntu\nDescription:    Ubuntu 21.10\nRelease:        21.10\nCodename:       impish\n\n\n$ grep -r . /sys/kernel/mm/transparent_hugepage/*\n/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise [madvise] never\n/sys/kernel/mm/transparent_hugepage/enabled:always [madvise] never\n/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152\n/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:1\n/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256\n/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000\n/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511\n/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096\n/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64\n/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000\n/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0\n/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19\n/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force\n/sys/kernel/mm/transparent_hugepage/use_zero_page:1\n\n$ cat /proc/90/stack | wc\n      0       0       0\n\necho never > /sys/kernel/mm/transparent_hugepage/defrag\necho 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag\necho never > /sys/kernel/mm/transparent_hugepage/enabled\n\n$ grep -r . /sys/kernel/mm/transparent_hugepage/*\n/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise madvise [never]\n/sys/kernel/mm/transparent_hugepage/enabled:always madvise [never]\n/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152\n/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:0\n/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256\n/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000\n/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511\n/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096\n/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64\n/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000\n/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0\n/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19\n/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force\n/sys/kernel/mm/transparent_hugepage/use_zero_page:1\n\n

\n

基本上，解决方法的来源是Fedora 错误报告 \xe2\x80\x9ckhugepaged eat 100%CPU\xe2\x80\x9d。该错误从未得到修复，“解决方案”适用于 2013 年的 Fedora 17，并且

\n

\n

在过去 3 个，也许是 4-5 个版本的 Fedora Kernels 中，我没有再遇到过这个问题。

\n

\n

但现在又发生了。

\n

Answer 1

这是我在 Ubuntu 20.04 上的解决方案：

1. 关闭虚拟机
2. 使用文本编辑器打开 VM 的 <vm_name>.vmx 文件
3. 将以下内容添加到 vmx 文件的末尾：

# Fix problem where vmware battles with kcompactd0.
vm.compaction_proactiveness=0

4. 保存文件并重新启动VM

[更新 2022-03-06]：如果您升级到 VMware Workstation Pro 16.2.1，请确保在测试之前将虚拟机升级到 16.2 并重新启动计算机。升级后我没有重新启动，问题一直持续到重新启动。

[更新2022-11-28]：查看“加速3D图形”是否启用，如果不需要则禁用它。这可能是此问题的触发因素。

Answer 2

这实际上是一个 IOMMU 问题，解决方案包括在内核命令行启用它。在固件中启用 VT-d（Intel IOMMU 内核驱动程序）是不够的，修补compaction_proactiveness 和swappiness 只会限制这种行为，而无法解决根本原因。

我自己也遇到了这个问题（Ubuntu 22.04主机，内核版本5.15.0，VMware Player 16.2.4，Windows 10 guest）。当来宾计算机在 Firefox 中打开多个选项卡、打开数据库应用程序或两者兼而有之时，这种情况尤其明显。

值得注意的是，设置vm.compaction_proactiveness=0没有效果。设置vm.swappiness=10有一点帮助，但问题仍然存在。

尽管主机固件中启用了 VT-x 和 VT-d，但事实证明，至少在内核版本 5.15.0-46-default 中，内核是使用 intel_iommu 编译的，但默认情况下该配置是禁用的。因此，

cat /boot/config* | grep INTEL_IOMMU

返回（以及其他行）（注意 octothorpe 注释掉第二行）：

CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set

解决方案是将以下字符串添加到内核命令行中。这将启用 intel_iommu，修复来宾冻结，并防止kcompactd0将其 CPU 核心固定在 100%，至少到目前为止是这样：

intel_iommu=on

因此，对于 GRUB，编辑/etc/default/grub以将上述字符串添加到GRUB_CMDLINE_LINUX_DEFAULT，例如，

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

保存并关闭文件，然后运行：

# update-grub

重启即可生效。

对于systemd-boot，(a) 将上述字符串添加到单独的行中/etc/kernel/cmdline，或者 (b) 将以下密钥添加到启动条目 .conf 文件中/loader/entries：

options intel_iommu=on

保存并关闭文件，然后重新启动即可生效。

编辑

这个问题部分仍然是 IOMMU 问题，但出现了一些附加信息：

• 如上所述配置 IOMMU 有很大帮助，但不是决定性的。问题再次出现。
• 毫不奇怪，这个问题涉及 Windows 客户机的内存管理和 Linux 主机的内存管理之间的相互作用。具体来说，配置 Windows 来宾以禁用应用程序的 Superfetch 功能（但不启动）有很大帮助。Superfetch 会预加载它认为您在启动时需要的内容，因此稍后加载速度会更快。所有这些都进入 RAM，增加了虚拟机的 RAM 消耗并减少了恢复和压缩的空间。关闭它允许按需加载和卸载。
• 另外，在虚拟机设置中减少 VMware VM 的 RAM 配置也有很大帮助。乍一看这似乎违反直觉，但 VMware Player 从一开始就从主机系统中占用了所有这些 RAM，从而使主机没有太多空间用于重新分配和压缩。在安装了 16GB (16384MB) RAM 的系统上，将 VM RAM 从 ~12GB 减少到 8192MB 实际上消除了我的问题。
• 尽管有上述情况，该问题更有可能在使用几个小时后（即当天晚些时候）发生。冻结的持续时间要短得多（几秒，而不是几分钟），但一旦开始，它就会继续这样做。据推测，事情并没有卸载，无论是主人还是客人还不清楚。完全关闭客户机（而不是重新启动，这会使 VMware Player 及其 RAM 抢占运行）可以是有效的重置。有时，还需要重新启动主机。
• Firefox 可以索取且不会放弃大量 RAM，至少在默认设置下是如此。这可以在其高级设置中进行一些配置。

敬请关注。