[arch-general] KDE plasma, baloo and UI/video playback freezes
carstenmattner at gmail.com
Tue May 8 19:08:35 UTC 2018
On 5/8/18, Francesco Porro via arch-general <arch-general at archlinux.org> wrote:
> 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
> 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 at 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.
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.
More information about the arch-general