Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy

Mike Galbraith (efault@gmx.de)
Tue, 15 Jul 2003 06:56:33 +0200


At 10:22 AM 7/14/2003 -0700, Davide Libenzi wrote:
>On Mon, 14 Jul 2003, Mike Galbraith wrote:
>
> > Yes, and it worked fine. No cpu load I tossed at it caused a skip.
>
>I tried yesterday a thud.c load and it did not get a single skip here
>either. It is interesting what thud.c can do to latency (let's not talk
>about irman because things get really nasty). With a simple `thud 5` the
>latency rised to more then one full second, as you can see by the graphs
>inside the SOFTRR page. No buffer size can cope with that.

Yes, thud is well named. It's easy to kill, but not so easy to kill
without hurting important dynamic response characteristics and/or
interactivity.

For sound purposes, all you have to do is make damn sure that thud/others
can't get to the queue where your sound client lives. I'm using a very
short term weighted slice_avg for that... your %cpu is calculated for each
slice, and once you approach interactive status, it doubles for each
priority you climb. That makes it very hard indeed for a cpu hog to ever
reach the top. Almost nothing can touch xmms here. It doesn't provide the
nearly 100% guarantee that SOFT_RR does, but otoh, it's absolutely
impossible to abuse.

(my best interactive effort combined that with non-linear decay, and
throttled backboost to offset the fairness pain that X any friends feel...
it's quite good, but [butt ugly and:] not quite good enough)

-Mike

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