Why not mainline it?

Posted Apr 21, 2017 1:02 UTC (Fri) by droundy (subscriber, #4559)
Parent article: The MuQSS CPU scheduler

I can understand Kolias not being interested in the effort to do so, but it sounds like a scheduler that would be of wide interest. Is there any other reason not to mainline this?

Why not mainline it?

Posted Apr 21, 2017 2:18 UTC (Fri) by conman (guest, #14830) [Link] (2 responses)

Linus has said in the past that he absolutely detests specialisation and doesn't want more than one scheduler in mainline. It's the same reason the "plugsched" pluggable CPU scheduler framework that went along with the original alternative schedulers, staircase, RSDL and staircase deadline was abandoned. Therefore it would have to replace the mainline scheduler en-bloc. As a hobby amateur coder working on a scheduler in one's spare time, there would be zero chance of creating something that meets all the criteria of trumping every mainline performance benchmark and feature to replace CFS.

Why not mainline it?

Posted Apr 21, 2017 4:57 UTC (Fri) by liam (guest, #84133) [Link]

Your comment brought this to mind

https://lists.linuxfoundation.org/pipermail/ksummit-discu...

It's an unfortunate thing that success can have downsides.

Lots of block schedulers though.

Posted Apr 30, 2017 5:11 UTC (Sun) by gmatht (subscriber, #58961) [Link]

I find it ironic that the LWN story next to this was "Two new block I/O schedulers for 4.12".

Any reason why? I guess there is a big single jump from rotational to SSD block devices that justifies at least two specialised block schedulers.

Why not mainline it?

Posted Apr 21, 2017 6:24 UTC (Fri) by mtaht (subscriber, #11087) [Link]

Ironically I have been looking into similar methods for better handing packet scheduling across multiple queues and pieces of hardware to eliminate microbursts and the like. I'd settled on skip lists, a similar runqueue, and a similar deadline scheduler... long before reading this article. Also key is trying to push a few difficult things back into hardware where they belong so things can scale better past 10gigE.

That is a hobby project just now, I'm not trying to change the world, just take a fresh look at the design space.

Why not mainline it?

Posted Apr 21, 2017 13:29 UTC (Fri) by Sesse (subscriber, #53779) [Link] (4 responses)

The primary reason is that there are no actual tests indicating it's any better, short of hearsay. When BFS first came out, the Android team did blind user studies, and it didn't live up to the hype.

Why not mainline it?

Posted Apr 21, 2017 14:04 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

This sounds like the biggest reason to have pluggable schedulers: so the system can randomly switch between schedulers every few minutes and not tell you which one is running. Then you could report your subjective experience of smoothness by pressing a button or something, and have a proper blind trial.

Why not mainline it?

Posted Apr 21, 2017 17:25 UTC (Fri) by iabervon (subscriber, #722) [Link] (2 responses)

Pluggable schedulers would be a much harder problem, because most schedulers look at what processes did in the recent past in order to decide about policy. So, at best, switching schedulers will detune your performance when it happens.

That sort of comparison would probably just tell you which scheduler benefits least from tracking, since you probably won't be able to notice the difference in smoothness between two schedulers at steady state, as compared to the glitch when you switch to one that needs its information on what you're watching.

Why not mainline it?

Posted Apr 23, 2017 17:17 UTC (Sun) by epa (subscriber, #39769) [Link] (1 responses)

Right, so the period of switching between the two should be reasonably long (though surely ten minutes is enough?) and any user reports soon after switching to a new scheduler would have to be disregarded (again, surely one minute is enough for the scheduler to be warmed up again?).

Are you saying that, on a typical interactive workload, a scheduler tunes its decisions using more than just the last few seconds of activity?

Why not mainline it?

Posted Apr 23, 2017 21:22 UTC (Sun) by iabervon (subscriber, #722) [Link]

I'd expect, with a typical interactive workload, there are: (1) some things that are going to do work when some external, invisible to the user, trigger occurs (web page loads/updates); (2) some things that happen continuously (video); and (3) some things that are going to do work which will be visible to the user, but don't have anything to do until the user does something (rendering text the user types). Prioritizing (3) when it has something to do over (1) requires paying attention when the user does something, which could be arbitrarily long ago.

The MuQSS thesis is that that kind of tracking isn't really beneficial (i.e., you can get (3) enough time despite (1) based on behavior at the time), but if that's not true, you won't be able to see any benefits of that tracking if you weren't running CFS the last time you interacted with the type (3) program.