* Rene Herman <[email protected]> wrote:
> To me, the example rather serves as confirmation of what Kolivas has
> been saying; endlessly tweaking the tweaks isn't going anywhere.
but ... SD clearly regresses in some areas, so by that logic SD isnt
going anywhere either?
note that i still like the basic idea about SD, that it is an experiment
that if the only conceptual focus is on "scheduling fairness", we'll get
a better scheduler. But for that to work out two things have to be done
i think:
- 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.
note that SD at the moment produces ~10% more code in sched.o, and the
reason is that SD is more complex than the vanilla scheduler. People
tend to get the impression that SD is simpler, partly because it is a
net linecount win in sched.c, but many of the removed lines are
comments.
this "provide fairness" goal is quite important, because if SD's code is
not only about providing fairness, what is the rest of the logic doing?
Are they "tweaks", to achieve interactivity? If yes, why are they not
marked as such? I.e. will we go down the _same_ road again, but this
time with a much less clearly defined rule for what a "tweak" is?
note that under the interactivity estimator it is not that hard to
achieve forced "fairness".
So _if_ we accept that scheduling must include a fair dose of heuristics
(which i tend to think it has to), we are perhaps better off with an
interactivity design that _accepts_ this fundamental fact and separates
heuristics from core scheduling. Right now i dont see the SD proponents
even _accepting_ that even the current SD code does include heuristics.
the other one is:
- the code has to demonstrate that it can flexibly react to various
complaints of regressions.
(I identified a few problem workloads that we tend to care about and i
havent seen much progress with them - but i really reserve judgement
about that, given Con's medical condition.)
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
