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

[Mike Galbraith <efault@gmx.de>]

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