[SOLVED] kswapd0 freezing the system for a few seconds once a while

Lockywolf · 12-08-2020, 09:16 PM

Hello, everyone.

This started happening since I moved to a different laptop with the same Slackware on an SSD. The hardware configuration is very different from what I have been using before (/home is on and SSD now, intel video card).

I still have a swap partition on sdb2.

So what started happening on the new laptop: the system periodically freezes for a few seconds, with iotop showing high IO (>95%); READ and WRITE stay small, an order of kilobytes. This happens regardless of memory consumption, it may be that there is still >4Gb memory free.

Freezes disappear if swap is turned off, but I do use swap extensively, both for running a lot of software at the boot time (restoring from swap is faster than launching) and for hibernation.

How to debug this?

UPDATE:

I found part of the cause. My /tmp is on tmpfs, and the FS was constantly swapping out.
The problem is that it is slowing the system! weird. I'd expect the least used files in tmpfs to be swapped out.

walecha · 12-09-2020, 09:00 AM

Maybe you had some sysctl tuning for swapping?

I'm also using tmpfs for /tmp. I have 16 GB of RAM and my slackware almost never touching swap except when I had to hibernate. I'm using this sysctl tuning:

Code:

# cat /etc/sysctl.d/vm.conf
vm.swappiness=10
vm.overcommit_memory=1

Lockywolf · 12-09-2020, 07:36 PM

Code:

echo none > /sys/block/sdb/queue/scheduler
echo none > /sys/block/sda/queue/scheduler

echo 1 > /proc/sys/vm/vfs_cache_pressure
echo 50 > /proc/sys/vm/dirty_ratio # default is 20. Potential data loss.
echo 25 > /proc/sys/vm/dirty_background_ratio # default is 10. Potential data loss.

That's it, basically.

I actually wouldn't mind offloading tmpfs to swap. It shouldn't be slow. Say, you're building a lot of stuff from SBo, and build directories take about ~10-20 Gb of space. It should be fine to offload almost all of that into swap, as only a single package's data is used at the moment.

Lockywolf · 12-10-2020, 08:06 PM

Hm... everything is still slow for unknown reasons... both HDDs are fast, I don't know what's going on.

Lockywolf · 12-20-2020, 11:09 PM

Okay, the freezes almost disappeared with two tricks:

Turning off NCQ completely: add libata.force=noncq to the kernel boot string.
And turn on hdd caching in /etc/rc.d/rc.local: hdparm -W1 /dev/sda

I guess, NCQ could be tuned instead of being turned off, by setting the queue length, but I didn't bother.
I saw some improvements with using the mq-deadline scheduler and tuning the knobs, but at the moment the system is working fine with none scheduler, so I didn't bother tuning it again.

That's basically it.