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

[Carsten Mattner]

On 5/8/18, Francesco Porro via arch-general <arch-general at archlinux.org> 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 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.

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.