On 5/8/18, Francesco Porro via arch-general <arch-general@xxxxxxxxxxxxx> wrote: > 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.
