System76-Scheduler Is A New Pop!_OS Rust Effort To Improve Desktop Responsiveness

[mmstick]

I suppose other environments would have to be patched to support this, then.

Who is running Kwin on top of the Pop Shell?

Unless they have a way of getting that information through an extension or as a service, such as how gnome-shell provides window focus notifications to GNOME Shell extensions. I've heard devilspie2 offers scriptable window notification events on GTK desktops.

[mmstick]

At least I don't care about about the language it is written in, but if the project is effective. There is a variety of CPU schedulers on the Kernel-level already and noticed small improvements lately while using PDS/BMQ but nothing too major. As this project comes from the user-space side, is this a potential limitation?

It's in a different ballpark. A kernel-level scheduler has no knowledge about what processes it should be giving priority to. All it can do is offer a nice parameter that something in the userspace can configure. Processes have always had the ability to define their own nice values, but most of them avoid touching their own priority, even though ideally it might be useful if a process were to assign itself to 19 when they plan to be idle, and if compiler processes did this by default to avoid slowing down a developer's machine while the IDE is doing code completion as they type.

This does tweak the CFS to make it low latency, but it's also assigning nice values to userspace processes based on either a defined default or input from the window manager instructing it about which process in the system the user is actively interacting with. If you're interacting with a web browser, the web browser and its descendants would get high priority; whereas the Zoom, Discord, and Steam processes in the background would get a low priority. The kernel doesn't have that info, but the window manager does.

[skeevy420]

I'm sure they're referring to the automatic foreground and background process management. It requires that you have some way to tell the service about a window being focused. Pop!_OS is getting that information from pop-shell making a `SetForeground(pid)` DBus method call to the service.

I suppose other environments would have to be patched to support this, then.

Who is running Kwin on top of the Pop Shell?

[ms178]

At least I don't care about about the language it is written in, but if the project is effective. There is a variety of CPU schedulers on the Kernel-level already and noticed small improvements lately while using PDS/BMQ but nothing too major. As this project comes from the user-space side, is this a potential limitation?

[mmstick]

Already should.

I'm sure they're referring to the automatic foreground and background process management. It requires that you have some way to tell the service about a window being focused. Pop!_OS is getting that information from pop-shell making a `SetForeground(pid)` DBus method call to the service.

[skeevy420]

Seems an interesting idea if it makes a noticeable difference. Hopefully it can also work with different shells.


Although it is a Rust project, and to make things worse, it does not use GPL license. This will indeed trigger some of the purists out here.

Already should.

[V1tol]

Where is my popcorn

[Hans Bull]

If it was a scheduler written in C, C++ or Pascal, no one would give a ... about it, nor a headline.

[evasb]

I think MPL is a great compromise between strong copyleft and permissive licenses.

MPL can replace permissive licenses in 99% of the cases because it is non-viral.

[mmstick]

MPL-2.0 is a copyleft license that's effectively the Rust equivalent of the LGPL, so I'm sure it's fine with the purists. Proprietary forks aren't permitted, but linking statically is fine. You can integrate it into GPL, MIT, and Apache-2.0 projects without requiring a relicense. But unlike MIT and Apache-2.0 you can guarantee that anyone modifying the code has to open source it under the MPL-2.0 too. Seems like a win win proposition.