Why not mainline it?

Posted Apr 23, 2017 17:17 UTC (Sun) by epa (subscriber, #39769)
In reply to: Why not mainline it? by iabervon
Parent article: The MuQSS CPU scheduler

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.