@jiaxinslee, think you're right.
This hack, like others that have been suggested in various posts to address this phenomenon, e.g., fiddling with vm.compaction_proactiveness and vm.swappiness, turns out not to have eliminated the phenomenon entirely.
The hack did eliminate the phenomenon for a few days, and it also continues to improve performance. Nevertheless, the behavior returned, with intermittent episodes of kcompactd0 pinning its CPU core at 100%, freezing the guest, albeit not the host. The duration of the episodes is significantly less than before, however, perhaps only a minute or two instead of ten or twenty, or even hours.
One bit of memory jiu-jitsu I'm experimenting with is a host tmpfs share. Specifically, I createe a tmpfs on a host mount point via fstab. The host serves files via Samba, so the mount point is within an existing Samba share. Then, on the Windows 10 guest, I created a directory symbolic link to the host's tmpfs share (mklink /d C:\tmp \\server\share\tmpfs-mount-point) and edited %TMP% and %TEMP% to refer to the symlink. An alternative configuration would map a drive letter, e.g., T:\, to the tmpfs share and could be better for the purpose. Either way, this effectively gives me a RAM mount for temp files on the Windows guest's filesystem. It definitely has improved performance and responsiveness and we'll see whether it has any effect on the kcompactd0 behavior.
