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.
Hey, this is great! It’s always rather frustrating when my laptop locks up because I asked too much of it. It’s usually only a single process that I need to kill, but I end up hitting the power button because System Activity takes forever to open.
Sounds really great, I noticed this a lot in the last time and during testing of Plasma 5.11 beta… to a point where I thought the system is completly crashed and I had to reset. Can’t wait then for for Plasma 5.12 to arrive, I wish Plasma would had a monthly release as well 😉 Thanks, it will be an awesome feature!
Complements for your blogs, they’re are a great with lots of interesting insight information. Making kwin a real time process sounds as a very good thing. I hope the change is going to exceed your expectations ??
Ctrl-Alt-F1 to kill a window? You mean Ctrl-Alt-Esc?
Ctrl-Alt-F1 to log in into a VT then do killall or kill -9
You missed the whole bit about event processing not happening for kwin due to scheduling issues
Repaints would always need to be locked to vsync or at least a low enough value to avoid denial of service attacks on kwin by triggering repaints in a while(1) loop I’d imagine?
Sure, KWin’s repaint is locked to vsync. Otherwise this would be a horrible change.
**The key combination (e.g. Ctrl+Alt+F1) needs to go through KWin**
This makes me ask the question do we need a kernel fix.
https://www.kernel.org/doc/Documentation/SAK.txt
We have the option of setting SAK key but it really would be nicer of kernel could do switch to terminal so locked up Wayland compositor was not a death sentence. Even possible end up with nice level connect to having active display.
I see the Ctrl+Alt+F1 being done by compositor or X11 server is hang over from user space video drivers. We have kernel mode setting and maybe should update to kernel mode VT change to match up with the modern kernel mode setting.
Kernel Capabilities.
People rarely know about them.
And now responsiveness solved< simple, and beautiful.
I always a fan to hear and to use capabilities right.
Thank you.
Congratulations everybody.
Why is this related only to wayland? To me this feature seems independent and applicable also to the Kwin for X.
On X it’s not that useful to have it for KWin as KWin doesn’t do input there.
Thank you! Looks like anyone can get the same result just with a simple command until this is released:
sudo setcap ‘cap_sys_nice=eip’ /usr/bin/kwin_x11
No, there is actually code involved adjusting the scheduler policy. Just setting the cap_sys_nice doesn’t do anything.
This concerns me.
1- What is the impact on pro audio latency when the window systems (which should lose to audio and disk in that scenario) are at realtime priority? Seems like it will increase Xruns substantially.
2- I’m concerned about the number of lines of code running realtime. On my 2016 intel graphics laptop kwin_x11 runs at 20%-30% of the cpu when the taskbar is visible (even with compositing off and few widgets). This would be even more of a disaster if it was running realtime.
3- Where is plasma-desktop in this process priority? It also doesn’t seem like a good idea to have increased priority given its intermittent history of issues on my desktops.
4- The more lines of code running realtime the more bugs running under realtime priority.
If this is a small, very well audited critical core of code I can see this being a win. It concerns me with what I see in my daily kde use however.
Please give it a try and if something does not work report a bug!
Saying the obvious: this is not normal. The CPU usage of KWin should be at max 1 to 2 % on one core in an idle and normal usage situation. The cpu usage you have here indicates a problem: something is probably generating too many X events. Investigate what’s causing it.
That depends on many factors. If you just use the system for audio and don’t interact with the windowing system in any way, the windowing system is idle and does nothing. If your audio processes are also real time they will win against KWin as KWin takes the minimum priority in SCHED_RR. So any SCHED_FIFO or SCHED_RR with higher priority wins against KWin. Honestly I don’t expect this to be an issue. Multimedia is one of the primary reasons for this change. Running a video player in real time policy just doesn’t make any sense if the windowing system is not real time as well.
This change is about KWin, not about Plasma. Plasma is not changed.
Bugs are bad, bugs should be fixed. Luckily KWin has a very high quality, is probably the best tested window manager out there. Our Wayland implementation has a code coverage of 80 %, KWin core is at 60 % (though still lots of X11 code which isn’t covered and not run on Wayland). In the end it does not matter whether a bug is running in real time or not. It’s a bug. The situation is different for freezes, but these are very seldom in the case of KWin and normally fixed before the code ships to users.
I’m sorry but It doesn’t seem a great solution but a workaround at best.
First On KDE sometimes I run some apps (Qjackctl, Ardour etc.) which require realtime access. And as you said Kwin is on the same “fast lane” with them when I render them in Wayland (we are supposed to switch to Wayland after sometime aren’t we?). If they made the same decision of running in the lowest possible realtime priority they lose the advantage.
Secondly for Ctrl + Alt + F1(2,3 ..). After each major version of Plasma 5 is released I go and try Wayland session. However, there is a common problem. KWin achieved many things but when I try to go back to my standard X11 session or simply reboot my computer It stucks so badly that I have to reset my computer using power button. With the hope of creating a bug report I tried to look for the log entries. Journalctl shows nothing. In the kernel logs everything as usual. It looks like kwin also exits normally. With no trace of errors I cannot report a useful bug report. But the fact that I cannot switch to TTYs because kwin is dead, is more disturbing and frustrating for me. I cannot get the current state of my session, I cannot look at the loginctl output. With the only reboot option left being the power button and without proper logs; it only makes me think Wayland is an ill-designed protocol. After thinking that to execute KWin (or any Wayland compositor) successfully, all of systemd, sddm and KMS must work perfectly. There is no option of a safe mode, no TTY, nothing. No, I don’t think that’s all KWin’s fault. But, I think KWin_Wayland must give the users an environment that can be rebooted, escaped or traced before It gets completed. If all of the compositors will have some workarounds for dealing the problems of Wayland standard it’s not different (and not an advancement) from X11.
Why should those apps use the lowest priority? And they probably use SCHED_FIFO, not RR as KWin. Please don’t just assume but give this a try! That’s why I ask for feedback.
Concerning your freezes: this was a known issue of sddm, not KWin. It is fixed afaik.
I’m using KDE neon development edition, is this already in? Because the UI feels much smoother now when I run my graphical application that uses a lot of GPU.
This was something that bothered me a lot because it made it very difficult to do any development with high CPU or GPU usage.
I just installed updates on my neon development edition and the capabilities are not yet set: so no, that’s not yet in.
Is nvidia driver still not works with kwin on wayland ?
To my knowledge NVIDIA still doesn’t support gbm, so no that is not supported.