Specialize Manjaro's scheduling behaviour for Desktop

Feedback Feature Request
1

I find it a huge dissapointment that by default, Manjaro does not come with kernel configuration to suit a desktop operating system. The following below are observations along with a suitable fix.

Problem #1:

  • Any high disk IO operation, especially prolonged ones, results in a staggering system, period. And it’s to be expected. There are however a few tweaks to ameliorate this problem and bring it to a “sane” desktop level.

    • An argument one might give is that the user is allowed to lower the IO priority of their task. This used to work with the cfq scheduler. That has been removed. Neither kyber nor does bfq handle priorities in an effective manner. mq-deadline makes the situation worse.

Solution:

  • The issue is primarily caused by a write_back cache buffer being incorrectly allocated, especially for machines with higher RAM than 4GB. Large amounts of data is preloaded in the buffer before it’s written to the actual disk medium, as big as cache size 9GB, which is, ridiculous. The fix is simple - ship manjaro with the kernel configured as follows. More information can be found at SUSE’s support/kb/doc/?id=000017857

To solve, reduce the buffer sizes and ratios.

  • vm.dirty_bytes=4194304
  • vm.dirty_background_bytes=4194304
  • vm.dirty_ratio=3
  • vm.dirty_background_ratio = 2

Problem #2:

  • The swap is being used too much and on disks rather than SSDs, the impact can lead to a low responsive system; tied in with the first issue. The VFS cache is also being reclaimed far too often, leading to thrashing.

Solution:

Give the kernel less of a tendency to reclaim VFS cache memory and to be less inclined to use the swap unless absolutely necessary.

  • vm.vfs_cache_pressure=10
  • vm.swappiness=10

Problem #3:

  • Audio crackling from ALSA/PulseAudio when high disk IO and high cpu IO. The sound/speaker buffers run out of data earlier than the consumer consumes them, not giving the callbacks the chance to feed the buffer fast enough. Again, to be expected. However, there are things that can be done to tune this to make it more malleable.

Solution:

  • Change the default priority, niceness and IO niceness of the audio driver/process to RT (realtime).

Problem #4:

  • The default scheduler that lands on SSDs is none, which is not the same as noop. Actually, forget this issue completely. There is a bigger problem with the kernel understanding user activity. When the disk is on high IO, the scheduler needs to change to the kyber scheduling algorithm, to suit IO requests. On a very heavily stressed machine, starvation occurs more often and several downloads [over 80] (notably HTTP ones) had increase risk of failure due to timeout responses being slow. I also don’t think I need to mention that bfq will suffer if high IO is present. Windows freeze, the mouse pointer barely moves, etc.

Solution:

  • After a thorough personal testing, bfq provides a more desktop oriented scheduler suited as default, for both HDD and SSD…
  • Provide an automatic means in the kernel to detect high IO and automatically switch from bfq to kyber. When the heurestic notices lower disk activity, switch back to bfq.
1 Like
2

Not two system use cases are identical - and one would prefer one over another.

How to tweak a given system for maximum performance is a matter of priorities and no use case are identical.

This is why the maxperfwiz [1] script exist - courtesy of @cscs and @Librewish - also take a look at how Linux handles cache [2].

As for timing - you can use a real time kernel - currently at linux59 - you could request[3] a rebuild of the kernel to 5.10

So for your requests - they are your personal priorities - and it is not possible for Manjaro to take into account every single personal preference.

You can see what patches are used for Manjaro kernels at gitlab[4] and you could use that as an entry point for your requests.

1 Like