LWN: Comments on "Extensible scheduler class to be merged for 6.11"

should the kernel have an engineering council?

Lennie — Sat, 17 Aug 2024 12:11:22 +0000

Well, at the moment if Linus somehow wasn't available long term, things would stay the same, except it would just be someone else at the top like Greg Kroah-Hartman.

The future looks bright

raistlin — Fri, 14 Jun 2024 01:07:55 +0000

The Steam games part is already happening, as sched_ext is being evaluated (i.e., they have a scheduler already, with benchmarks results, etc) for the Steam Deck:

https://lore.kernel.org/lkml/20240501151312.635565-1-tj@k...

> - Valve has been working with Igalia to implement a sched_ext scheduler for
> Steam Deck. The development is still in its early stages but they are
> already happy with the results (more consistent FPS) and are planning to
> enable the scheduler on Steam Deck.
>
> https://github.com/sched-ext/scx/tree/main/scheds/rust/sc...
> https://ossna2024.sched.com/event/1aBOT/optimizing-schedu...

And:

https://blogs.igalia.com/changwoo/sched-ext-a-bpf-extensi...
https://ossna2024.sched.com/event/1aBOT/optimizing-schedu...

Overriding the MAINTAINERS

alison — Thu, 13 Jun 2024 04:38:42 +0000

The last time I recall Linus overriding a top kernel contributor was when he decided to merge Android's binder and ashmem, which had been in staging for a long time. Apparently GKH was not enthusiastic about the merge, but Linus said something like, "Millions of people are using it, so we should merge it."

Regarding use cases, SCHED_EXT author Dan Schatzberg's talk at Southern California Linux Expo was excellent, and Daroc wrote about it for LWN: https://lwn.net/Articles/966618/

Current process is appeal to Linus

farnz — Wed, 12 Jun 2024 12:24:38 +0000

It does have such a process at the moment; Linus is the final arbiter (analogous to an "Engineering Council"), and if there's a deadlock that you think should be resolved in your favour, you go to Linus to get things resolved. Linus trusts his chosen maintainers, so the process is biased in their favour, but if they're being donkeys, Linus will break the deadlock - in the extreme, by doing what he's doing with sched_ext and merging it over maintainer objection.

Ultimately, the current kernel is structured with Linus as benevolent dictator; all a Council or Committee can do is make suggestions to Linus, and see if he takes them. Of course, the same applies to maintainers; while they suggest changes to Linus via pull requests, he has the ultimate authority over what changes will and will not be accepted.

should the kernel have an engineering council?

khim — Wed, 12 Jun 2024 12:21:34 +0000

Linus may always override any decision of any maintainer.

He uses that superpower very rarely, which is precisely how he may keep it: every time Linus does that some people become angry at him, obviously, and frequent application would make community leave Linus, but as long as he uses such superpower only once a year or even less often the majority of developers support him.

At some point kernel community would need to find a way to do that without Linus, but that that bridge would be crossed when it would be reached, there are no rush.

The future looks bright

farnz — Wed, 12 Jun 2024 10:49:52 +0000

The biggest set of experiments I expect to see are on the desktop; can you schedule based on knowledge of what the user can see and interact with, such that while overall system throughput is down, user-perceived responsiveness is up? Can you schedule such that a Steam game (which itself involves multiple processes) gets a lower maximum time per frame?

should the kernel have an engineering council?

danielkza — Wed, 12 Jun 2024 09:47:35 +0000

It's nice to see Linus injecting some sanity into the discussion, but it would be preferable to have a process of some sort so these kinds of deadlocks can be resolved in a consistent way.

I believe there kernel should have something analogous to distributions' Engineering Councils to settle these types of disputes. While maintainer authority is important, there must be checks to stop it from being used across reasonable subsystem barriers and/or in obstructionist ways (even if with good intentions).

Scheduling

mattburgess — Wed, 12 Jun 2024 07:46:45 +0000

Well played sir, well played. That gets my nomination for QOTW!

The future looks bright

WolfWings — Wed, 12 Jun 2024 06:36:53 +0000

Honestly I expect a fairly large amount of schedulers to appear, and the major distros to end up with their own scheduler flavors available. "Desktop" vs "Server" installs will actually make a difference in that regard more likely at a minimum.

Scheduling

epa — Wed, 12 Jun 2024 06:31:27 +0000

A new property of schedulers: guaranteed sane progress.

The future looks bright

iq-0 — Wed, 12 Jun 2024 05:54:32 +0000

After all the talks about it I’m curious how merging this will make (applied) scheduler research more practical and how that’ll lead to improvements to the generic scheduler in the time to come.

Great News

jason.rahman — Tue, 11 Jun 2024 23:16:18 +0000

Wow, a bit surprising (in a good way) to see this. The rest of the community was clearly rallying around sched_ext and demonstrating clear wins, Ubuntu in particular was very openly showing good improvements. I suppose Linus saw the writing on the wall that a lot of folks were on the cusp of adoption but as an out of tree patch set.