kcompacd0 using 100% CPU with VMware Workstation 16

Question

Same as posted in redhat bugzilla -- kcompacd0 using 100% cpu, which was closed for INSUFFICIENT_DATA.

Also same as

• VMware on Linux host causes regular freezes
• Arch Linux becomes unresponsive from khugepaged

Reopening because the solution there doesn't work for me.

Here is my situation:

• Ubuntu 21.10 host and Windows 10 Enterprise client, with VMware Workstation 16 v16.2.0 build-18760230
• I'm not doing anything fancy or heavy load, just after a day of regular Windows 10 usage (of light load), things start to get wild.
• The process kcompactd0 is constantly using 100% cpu on one core, and vmware-vmx using 100% cpu on eight cores.
• When it does, it'll normally last for several minutes. Then kicks in again after a minutes or two.
• "kcompactd0 goes away only with drop_caches. when it goes 100%, the vmware virtual machine guest is completely unresponsive (windows 10 ltsc vm)" So I only tried drop_caches once, and have confirmed the behavior.

As requested upstream, here is more info:

$ 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

Basically the source of the workaround is in a Fedora bug report “khugepaged eating 100%CPU”. The bug was never fixed, and the "solution" was meant for Fedora 17 in year 2013, and

with the last 3, maybe 4-5 versions of Fedora Kernels I haven't encountered that issue again.

But it is happening again now.

Answer 1

This actually is an IOMMU issue and the solution involves enabling it at the kernel command line. Enabling VT-d (the Intel IOMMU kernel driver) in the firmware isn't enough and tinkering with compaction_proactiveness and swappiness only constrain this behavior without addressing the underlying cause.

I encountered the problem myself (Ubuntu 22.04 host, kernel version 5.15.0, VMware Player 16.2.4, Windows 10 guest). It was especially pronounced when the guest machine had multiple tabs open in Firefox, open database apps, or both.

Notably, setting vm.compaction_proactiveness=0 had no effect. Setting vm.swappiness=10 helped a bit but the issue persisted.

Notwithstanding that VT-x and VT-d both were enabled in the host firmware, it turns out that, at least with kernel version 5.15.0-46-default, the kernel is compiled with intel_iommu but the configuration is disabled by default. Thus,

cat /boot/config* | grep INTEL_IOMMU

returns (among other lines)(note the octothorpe commenting out the second line):

CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set

The solution is to add the following string to the kernel command line. This enables intel_iommu, fixes the guest freezes, and keeps kcompactd0 from pinning its CPU core at 100%, at least thus far:

intel_iommu=on

So, for GRUB, edit /etc/default/grub to add the above string to GRUB_CMDLINE_LINUX_DEFAULT, e.g.,

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

Save and close the file, then run:

# update-grub

Reboot to take effect.

For systemd-boot, either (a) add the above string to a separate line in /etc/kernel/cmdline or (b) add the following key to your boot entry .conf file in /loader/entries:

options intel_iommu=on

Save and close the file, then reboot to take effect.

EDIT

This matter continues to be an IOMMU issue in part but some additional information has come up:

• Configuring IOMMU as above helps greatly but not definitively. The problem recurs.
• The issue not surprisingly involves an interplay of the the Windows guest's memory management and the Linux host's memory management. Specifically, configuring the Windows guest to disable its Superfetch function for applications (but not boot) helped immensely. Superfetch pre-loads stuff it thinks you'll need at startup, so it will load faster later on. All of that goes into RAM, increasing the VM's RAM consumption and reducing headroom for recovery and compaction. Turning that off allows load and unload on demand.
• Separately, reducing the VMware VM's RAM configuration in Virtual Machine Settings helps a great deal. This may seem counterintuitive at first but VMware Player claims all of this RAM from the host system from the outset, leaving the host without much headroom for reallocation and compaction. Reducing VM RAM from ~12GB to 8192MB on a system having 16GB (16384MB) installed RAM virtually eliminated the problem for me.
• The foregoing notwithstanding, the issue is more likely to occur after several hours' use, i.e., late in the day. The duration of the freezes is far shorter (seconds, not minutes) but once it starts, it keeps doing it. Presumably, things aren't unloading that should, whether with host or guest isn't yet clear. A full shutdown of the guest (not a restart, which leaves VMware Player and its RAM preemption running) can be an effective reset. Occasionally, a host reboot also is necessary.
• Firefox can claim and not relinquish vast amounts of RAM, at least with is default settings. This can be configured somewhat in its advanced settings.

Stay tuned.

Answer 2

This is the solution for me on Ubuntu 20.04:

1. Shut down the VM
2. Open the <vm_name>.vmx file for the VM using a text editor
3. Add the following to the end of the vmx file:

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

4. Save file and restart VM

[Update 2022-03-06]: If you upgrade to VMware Workstation Pro 16.2.1, make sure you upgrade your VMs to 16.2 and reboot your machine before testing. I did not reboot after upgrading and the issue persisted until the reboot.

[Update 2022-11-28]: See if "Accelerate 3D Graphics" is enabled, and disable this if its not required. This may be a trigger for this issue.

Answer 3

echo 0 > /proc/sys/vm/compaction_proactiveness

or

sudo sh -c 'echo 0 > /proc/sys/vm/compaction_proactiveness'

Source: https://gist.github.com/2E0PGS/2560d054819843d1e6da76ae57378989

Answer 4

Not a "solution" per se but it's a solution for me:

...I find the behavior and responsiveness to be really, really slow and it regularly demonstrates a very jerky lack of responsiveness. While running a VM the entire OS will become unresponsive for 30 seconds to minutes at a time and then I will regain some level of control for a little while and then the system reverts to an unresponsive state ... rinse, wash, repeat ...

I have tried uninstalling and reinstalling the software (VMware Workstation 16) several times and this has not made any difference at all.

So ... I tried an experiment ... I installed Oracle VirtualBox to see how that would perform.

Well ... what a difference!!

I have 2 Windows 10 VM's, each with 8GB or RAM, and a Windows 2008 server, a Windows XP system, and 3 Ubuntu VM's (all the old systems are because I am doing Kali / Metaspolit training) and with ALL of these running at the same time the entire OS and each of the VM's hums along without a care in the world.

The system is actually behaving the way I would expect when running all of these VM's. Bottom line here is that I have been struggling with extremely frustrating poor performance using VMware Workstation 16 for months, and months and VirtualBox is blowing it away.

In general I love VMware, I have a Raspberry Pi ESXi cluster and an Intel NUC running ESXi all reporting into a vCenter instance, we use VMware at work, etc., etc. but I just cannot bear to use VMware Workstation when experiencing this abysmal performance.

Answer 5

I had the same issue in VMware Workstation 17 and 17.5 on Debian Linux.

I wonder if this issue is related to using the setting Fit all virtual machine memory into reserved host RAM, which can be found in the Preferences of the VMware GUI. Maybe along with a too-high setting of "Reserved Memory" in the same settings pane.

I have changed these settings, especially now using Allow some virtual machine memory to be swapped, in hope of this resolving this issue.