Hacker News new | ask | show | jobs
by flohofwoe 883 days ago
That such a simple 2D game isn't able to reach 60fps under heavy system load just shows that the vanilla scheduler doesn't boost the process associated with the currently active window though?

Shouldn't this be standard on all 'desktop' operating systems, e.g. anything associated with the user gets higher priority than anything else happening on the system? Even the Amiga had such a priority-boosting system back in 1985 (otherwise multitasking wouldn't be of much use on such a slow computer, because pretty much any background task would make the UI unusable).

2 comments

How would the vanilla scheduler know which process is associated with the currently active window? You're assuming there's more cooperation between the various layers of a linux desktop than I think there really are.
The scheduler doesn't need to know which process is associated with the currently active windows.

Simple heuristics can get you which to "reasonably" guesstimate which process are interactive and which aren't. For example, every X and descendant, or everything waiting on keyboard/controller or any other input.

I think the linux kernel historically did not want to prioritize interactive processes like windows and macos does.

The other thing is of course to reduce the CPU quanta, trading latency for throughput. I think most modern distribution do ship with better quanta for smooth GUI/desktop behavior.

One would think that at least a rewrite-from-scratch effort like Wayland would have come up with a solution.

Unfortunately the same problem also exists on other systems. Visual Studio even had to add a feature "Run build at low process priority" for the system to remain usable during builds:

https://devblogs.microsoft.com/cppblog/msbuild-low-priority-...

I mean the end-user can always write the glue required to get the current running window get its process and mark that as the "high priority", but that's still working under the constraints of the regular scheduler.
Amiga had no such thing.

exec.library is a RTOS kernel with a round-robin scheduler and (strict) priorities.