4 ms·
Your compositor could already be run at realtime priority... the risk is if the process has bugs which may result in infinite loops, you may lose the ability to
by pengaru 4y ago
Your compositor could already be run at realtime priority... the risk is if the process has bugs which may result in infinite loops, you may lose the ability to interact with the system.
- PlutoIsAPlanet 4y agoWouldn't you also need some kind of priority system in the graphics system? If you have a game open using all the available GPU resources, doesn't matter if you can't block input if you can't get any updates to the screen.
- pengaru 4y agoWell, for anything actually putting pixels on the screen under the compositor's purview, the compositor controls the framerate of the game and there needs to be context switching involving the scheduler to get things displayed. I'm not clear on what mechanisms exist today for preventing things like a DoS of GPU resources in something of a single entry to the GPU driver without returning to userspace. We've all seen things like GPU stalls reported in dmesg, so clearly the drivers are tasked with preventing that sort of hang where a process enters the driver and stays there far too long.
- jlokier 4y agoThe Linux kernel since 2.6.25 provides CPU time limits on real-time priority so that runaway real-time tasks don't prevent other interactive processes from having some CPU time. So you can still interact with the system. "man 7 sched" provides a lot of detail about the real-time scheduling policies and options. (Of course if the compositor is essential to the kinds of interaction you need, e.g via the GUI, you'll still be stuck if the compositor stops working. But that's not a real-time priority problem.)
- pengaru 4y agoNice! The last time I programmed something with SCHED_FIFO was long ago, and involved a lot of sysrq.