与 redhat bugzilla 中发布的相同 - kcompcd0 using 100% cpu已关闭INSUFFICIENT_DATA。
也一样
重新打开，因为那里的解决方案对我不起作用。
这是我的情况：
- Ubuntu 21.10主机和 Windows 10 Enterprise 客户端，带有 VMware Workstation 16 v 16.2.0 build-18760230
- 我没有做任何花哨或重负载的事情，就在正常使用 Windows 10 一天（轻负载）之后，事情开始变得疯狂。
- 该过程
kcompactd0不断在一个内核上vmware-vmx使用 100% cpu，在八个内核上使用 100% cpu。
- 当它发生时，它通常会持续几分钟。然后在一两分钟后再次启动。
- “kcompactd0 仅与 drop_caches 一起消失。当它达到 100% 时，vmware 虚拟机来宾完全没有响应（windows 10 ltsc vm）”所以我只尝试了 drop_caches 一次，并确认了该行为。
根据上游的要求，这里有更多信息：
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.10
Release: 21.10
Codename: impish
$ grep -r . /sys/kernel/mm/transparent_hugepage/*
/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise [madvise] never
/sys/kernel/mm/transparent_hugepage/enabled:always [madvise] never
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:1
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19
/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force
/sys/kernel/mm/transparent_hugepage/use_zero_page:1
$ cat /proc/90/stack | wc
0 0 0
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
echo never > /sys/kernel/mm/transparent_hugepage/enabled
$ grep -r . /sys/kernel/mm/transparent_hugepage/*
/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise madvise [never]
/sys/kernel/mm/transparent_hugepage/enabled:always madvise [never]
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:0
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19
/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force
/sys/kernel/mm/transparent_hugepage/use_zero_page:1
基本上，解决方法的来源是Fedora 错误报告“khugepaged eating 100%CPU”。该错误从未被修复，“解决方案”是针对 2013 年的 Fedora 17 的，并且
对于最后 3 个，也许是 4-5 个 Fedora 内核版本，我再也没有遇到过这个问题。
但现在又发生了。
或者
来源：https ://gist.github.com/2E0PGS/2560d054819843d1e6da76ae57378989
这是我在 Ubuntu 20.04 上的解决方案：
[2022-03-06 更新]：如果您升级到 VMware Workstation Pro 16.2.1，请确保在测试前将您的虚拟机升级到 16.2 并重新启动您的机器。升级后我没有重新启动，问题一直存在，直到重新启动。
本身不是“解决方案”，但对我来说是一个解决方案：
这实际上是一个 IOMMU 问题，解决方案包括在内核命令行中启用它。在固件中启用 VT-d（英特尔 IOMMU 内核驱动程序）是不够的，修改 compaction_proactiveness 和 swappiness 只会限制这种行为而没有解决根本原因。
我自己也遇到了这个问题（Ubuntu 22.04 主机，内核版本 5.15.0，VMware Player 16.2.4，Windows 10 来宾）。当来宾机器在 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）：
解决方案是将以下字符串添加到内核命令行。这启用了 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 问题，但出现了一些额外的信息：
敬请关注。