Re: Ten percent test

[Ingo Molnar]

* Rene Herman <rene.herman@xxxxxxxxx> wrote:

> > - the code actually has to match that stated goal. Right now it
> >   diverges from it (it is not a "fair" scheduler), and it's not 
> >   clear why.
> 
> I read most of the discussion centering around that specific point as 
> well, and frankly, I mostly came away from it thinking "so what?". 
> [...]

it's important due to what Mike mentioned in the previous mail too: SD 
seems to be quite rigid in certain aspects. So if we end up with that 
fundamental rigidity we might as well be _very_ sure that it makes 
sense. Because otherwise there might be no other way out but to "revert 
the whole thing again". Today we always have the "tweak the 
interactivity estimator" route, because that code is not rigid at the 
core of the scheduler.

> [...] one of them turn into a contrived heap of heuristics where every 
> progression on one front turns into a regression on another means that 
> one is on a dead-end road.

that's not what i found when testing Mike's latest patches - they 
visibly improved those testcases, part of which were written to 
"exploit" heuristics, without regressing others. Several people reported 
improvements with those patches.

Why was that possible without spending years on writing a new scheduler? 
Because the interactivity estimator is fundamentally _tweakable_. What 
you flag with sometimes derogative sentences as a weakness of the 
interactivity estimator is also its strength: tweakability is 
flexibility. And no, despite what you claim to be a "patchwork" it makes 
quite some sense: reward certain scheduling behavior and punish other 
type of behavior. That's what SD does too in the end. Sure, if your 
"reward" fights against the "punishment", they cancel out each other, or 
if the metrics used are just arbitrary and make no independent sense 
it's bad, but that's just plain bad engineering.

Why didnt much happen in the past year or so? Frankly, due to lack of 
demand for change - because most people were just happy about it, or 
just not upset enough. And i know the types of complaints first-hand, 
the -rt tree is a _direct answer_ to desktop-space complaints of Linux 
and it includes a fair bit of scheduler changes too. Now that we have 
actual new testcases and people with complaints and their willingness to 
try patches, we can do something about it.

> > the other one is:
> >
> > - the code has to demonstrate that it can flexibly react to various 
> >   complaints of regressions.
> 
> With one important point -- if every single _change_ in behaviour is 
> going to be defined a regression, then obviously noone will ever again 
> be able to change anything fundamental. [...]

i didnt say that, in fact my first lkml comment about RSDL on lkml was 
the exact opposite, but you SD advocates are _still_ bickering about 
(and not accepting) fundamental things like Mike's make -j5 workload and 
flagging it as unrealistic, so until there's so much reality disconnect 
there's not much chance for this issue to progress i'm afraid.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/