Today I landed a change in KWin master branch to enable real time scheduling policy for KWin/Wayland. The idea behind this change is to keep the graphical system responsive at all times, no matter what other processes are doing.

So far KWin was in the same scheduling group as most other processes. While Linux’s scheduler is completely fair and should provide a fair amount of time to KWin, it could render the system hard to use. All processes are equal, but some processes are more equal than others. KWin – as the windowing system – is to a certain degree more equal. All input and all rendering events need to go through KWin.

We can now imagine situations where a system can become unusable due to KWin not getting sufficient time slots. E.g. if the user moves the mouse we expect a timely cursor motion. But if KWin is not scheduled the system is quickly starting to lagging. Basically what we expect is that when the mouse moves with the next page flip the cursor must be at the updated position. A page flip happens normally every 16 msec (60 Hz), so if we miss one or two we are in the area where a user visually notices this. For a gamer with a high precision mouse this could be quite problematic already.

Another situation is a few processes running amok and one wants to switch to a virtual terminal to kill the processes. The key combination (e.g. Ctrl+Alt+F1) needs to go through KWin. Again the user wants to have a responsive system in order to be able to switch the session.

While thinking about these general problems I came to the conclusion that we should try making KWin a real time process. This would ensure that KWin gets the CPU whenever it wants to have the CPU. This is actually quite important: KWin is only taking CPU if there is a reason for it, e.g. an input event or a window requesting a repaint, etc. So by adding a real time scheduling policy to KWin we can ensure that all input events and all rendering events are handled in a timely manner. My hope is that this in general results in slightly smoother experience and especially in a smoother experience if the system is under heavy load.

Of course I considered the disadvantages. If KWin is a real time process, it always wins. It’s on the scheduler’s fast lane. This could of course be a problem for other processes actually demanding a higher scheduling policy or which are real time itself. E.g. a game or a video player might already be real time. But here we also see that there is no point in having the game be real time for fast input if the windowing system itself is not real time. So this is actually not a disadvantage, but rather another reason to make KWin a real time process.

There could be other real time processes which are more important. Of course those should win against KWin. To support this KWin requests only the minimum priority, so any other real time process in the system is considered more important than KWin.

The only real “problem” I see would be KWin running amok, because then KWin would get too much CPU time. But in this case the system would be broken anyway. If e.g. KWin would be stuck in an endless loop one would not be able to switch to another VT as KWin is stuck in the endless loop. This is obviously only a theoretical example.

So how is it done? KWin gained a new optional dependency on libcap and on installation sets the capability CAP_SYS_NICE on the kwin_wayland binary. @Distributions: please update your build deps. On startup kwin_wayland adjusts the scheduler policy to request SCHED_FIFO and drops the capability again before doing anything else.

As this change is in master it won’t be part of the Plasma 5.11 release which also means we have now the maximum time span till it ends up in a release. I would be happy about users testing it and especially report any negative influences of the change.