kswapd often uses 100% CPU when swap is in use

Most of the time when my computer starts to need swap, I see a massive spike in CPU usage (kswapd0 is consistently using 99%-100% CPU). According to top, the time is spent in sy (system/kernel) not wa (IO wait).

I am running Linux 4.0.4-2-ARCH on a C720 with 2GB RAM, and 6GB swap on an SSD.

I seem to have this problem with or without discard pages (TRIM) turned on.

Are there any setting I should inspect or tweak to see if I can fix this?

Is there any way to debug the problem? Something like strace for kernel threads?

Running with default Arch Linux settings:

/proc/sys/vm/swappiness = 60
/proc/sys/vm/vfs_cache_pressure = 100
/sys/kernel/mm/transparent_hugepage/enabled = [always] madvise never

It seems a relatively common problem

When the problem is happening, can you check if issuing the following command stops it: echo 1 > /proc/sys/vm/drop_caches

If it works, you can schedule it as a periodic cron job as a workaround.

I have a C720 running Linux Kernel 4.4.0 on Ubuntu 14.04.1 LTS with 2 GB RAM and 2 GB swap.

Assuming heavy Chrome/Chromium usage, here are some ways to make your system more performant:

1. Edit /etc/default/grub and add the following kernel parameters to the GRUB_CMDLINE_LINUX_DEFAULT line:
   • elevator=noop
   • zswap.enabled=1
   • transparent_hugepage=madvise
2. Run sudo update-grub2.
3. Edit /etc/sysctl.conf and append the following:
   • vm.swappiness=25 # ~ max(RES in top)*2 / RAM = 500 MB / 2 GB
   • vm.vfs_cache_pressure=1000 # safer than periodically dropping caches
4. Reboot.

You can verify the changes like so:

$ dmesg | grep -i noop
[    0.694680] io scheduler noop registered (default)
$ dmesg | grep -i zswap
[    0.724855] zswap: loaded using pool lzo/zbud
$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
$ sysctl vm.swappiness
vm.swappiness = 25
$ sysctl vm.vfs_cache_pressure
vm.vfs_cache_pressure = 1000

Update

Increasing vm.min_free_kbytes in step #3 may be beneficial. Try a value of 131072 (128 MB). The final takeaway is that Linux on the desktop doesn't perform very well in low-memory situations. Some have suggested placing Chrome/Chromium in a cgroup, but that's beyond the scope of this answer.