[arch-general] KDE plasma, baloo and UI/video playback freezes

Francesco Porro frapox at gmail.com
Tue May 8 20:59:20 UTC 2018


In data martedì 8 maggio 2018 21:08:35 CEST, Carsten Mattner ha scritto:
> Linux block layer's writeback system was supposed to fix this,
> but I've also noticed that the mechanism isn't perfect and
> you can still have a "hanging" application when doing the
> infamous USB-to-USB transfer that kills the VM subsystem.
> 
> Another way I can reproduce it is when there SSD-to-thumb-drive
> and you decide to some disk activity, too.
> 
> https://lwn.net/Articles/682582/
> 
> The problem is that VM gets pressured a lot and the whole
> construct fails in a way, while working as designed,
> manifesting as hanging programs.

Ok, but I'm talking about HDD on Sata bus. No Usb-to-usb transfers 
involved. And, as said before, I've altready tweaked the 
vm.dirty{writeback,background_ratio} to partialy word around this, 
either on Debian or Arch linux.

> First, to confirm, if you manage to run the indexer like
> you would `ionice -c idle <the-indexer>`, and it shows
> less hangs, you know the issue is unfair I/O queuing.

The indexer's process autostarts and rapidly kills himself in a bunch of 
seconds... its impossible to renice the process, however I saw (by 
Ksysguard) it's always 19 as nice value... meaning high fairness both 
for the CPU, and I think for the IO too.


> You can compare the block layer kernel configuration of
> Debian vs Arch.

Sorry, how to? Which are the keyword for searching?

> You can try deadline or bfq schedulers. One is dead simple
> and the other optimizes for desktop responsiveness.

As a last chance, I'll look into these alternatives schedulers. But now,  
either Debian or Arch are using the same one: Cfq. So I don't think this 
is the cause of the problem.

-- 
fp


More information about the arch-general mailing list