* Rene Herman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
