On 5/8/18, Francesco Porro via arch-general
Hi,
My problem is: when I'm watching a video, running Konversation in the background with logging on disk enabled, the playback of video slows down, freezes for a while.
Running iotop and ksysguard I found that baloo_file_extractor is writing on disk a big amount of data, filling the write queue; balooct monitor shows baloo is indexing Konversation's logs file changes. Peaks of 60-90 MB/s of data on mechanical hdd are generated and the playback of videos (or audio, or other GUI-related tasks) slow down or freeze. Very very annoying.
I'm running updated versions of: KDE plasma (5.12.5), kernel (4.16.7), baloo (5.45); CFQ I/O scheduler on sda.
On the same machine, the same version of softwares, the same configurations (of programs, mounts, IO scheduler) BUT on a Debian sid install (home is shared between installs) is NOT showing the same issue. On Debian, playback is running smootly even if baloo_file_extractor is heavly loading IO writes queue.
On each installation I added this tweaks, to improve Vm management by the kernel:
[frapox@tungsteno ~]$ cat /etc/sysctl.d/local.conf vm.dirty_background_ratio = 2 vm.dirty_ratio = 5 vm.vfs_cache_pressure = 60
I also tried to recompile the Arch kernel with CONFIG_PREEMPT_VOLUNTARY=y, to reflect the same default compile setting of Debian, but the issue wasn't solved.
So i'm wondering which other config files or settings/tweaks I can look into to overcome this issue on Arch linux (I'd really love to keep on use Arch as my main OS).
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. 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. You can compare the block layer kernel configuration of Debian vs Arch. You can try deadline or bfq schedulers. One is dead simple and the other optimizes for desktop responsiveness.