Kyber scheduler brings system to halt when used on swap partition

Kyber scheduler brings system to halt when used on swap partition

[Markus Trippelsdorf]

Using the new Kyber mq scheduler brings my system to a halt as soon as it
starts swapping. The swap partition resides on an SSD and is the only
partition in use on that drive.
Symptoms are stuttering sound and non moving mouse pointer. After a
while the monitor switches off, because it gets no signal anymore.
At which point only a hard reset will bring the system back.

"none" works fine.

-- 
Markus

Re: Kyber scheduler brings system to halt when used on swap partition

[Omar Sandoval]

On Thu, May 11, 2017 at 02:57:24PM +0200, Markus Trippelsdorf wrote:
> Using the new Kyber mq scheduler brings my system to a halt as soon as it
> starts swapping. The swap partition resides on an SSD and is the only
> partition in use on that drive.
> Symptoms are stuttering sound and non moving mouse pointer. After a
> while the monitor switches off, because it gets no signal anymore.
> At which point only a hard reset will bring the system back.
> 
> "none" works fine.

Thanks for testing, I'm taking a look to see if there's anything special
about the swap path that would trigger this. In the meantime, if you
swapoff your swap partition and do some I/O on it, what happens? Here's
a first-order guess at a fio job you could run:

fio --group_reporting --filename=$partition \
	--name swapin --numjobs=8 --ioengine=sync --rw=randread \
	--name swapout --numjobs=4 --ioengine=libaio --iodepth=8 --rw=randwrite

Interesting to note is that wbt, which Kyber borrowed ideas from, treats
kswapd specially, allowing it to queue more I/O than other processes. I
wonder if we need to do the same in Kyber.