* Con Kolivas <[email protected]> wrote:
> > I was more focused on the general case, but all I should have to do
> > to de-claw all of these sleep exploits is account rr time (only a
> > couple of lines, done and building now). It's only a couple of
> > lines.
>
> The more you try to "de-claw" these sleep exploits the less effective
> you make your precious interactive estimator. Feel free to keep adding
> endless tweaks to undo the other tweaks in order to try and achieve
> what SD has by design.
firstly, testing on various workloads Mike's tweaks work pretty well,
while SD still doesnt handle the high-load case all that well. Note that
it was you who raised this whole issue to begin with: everything was
pretty quiet in scheduling interactivity land. (There was one person who
reported wide-scale interactivity regressions against mainline but he
didnt answer my followup posts to trace/debug the scenario.)
SD has a built-in "interactivity estimator" as well, but hardcoded into
its design. SD has its own set of ugly-looking tweaks as well - for
example the prio_matrix. So it all comes down on 'what interactivity
heuristics is enough', and which one is more tweakable. So far i've yet
to see SD address the hackbench and make -j interactivity
problems/regression for example, while Mike has been busy addressing the
'exploits' reported against mainline.
> You'll end up with an incresingly complex state machine design of
> interactivity tweaks and interactivity throttlers all fighting each
> other to the point where the intearactivity estimator doesn't do
> anything. [...]
It comes down to defining interactivity by scheduling behavior, and
making that definition flexible. SD's definition of interactivity is
rigid (but it's still behavior-based, so not fundamentally different
from an explicit 'interactivity estimator'), and currently it does not
work well under high load. But ... i'm still entertaining the notion
that it might be good enough, but you've got to demonstrate the design's
flexibility.
furthermore, your description does not match my experience when using
Mike's tweaks and comparing it to SD on the same hardware. According to
your claim i should have seen regressions popping up in various,
already-fixed corners, but it didnt happen in practice. But ... i'm
awaiting further SD and Mike tweaks, the race certainly looks
interesting ;)
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]
