Messages in this thread | | | Date | Tue, 15 Jul 2003 06:56:33 +0200 | From | Mike Galbraith <> | Subject | Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy ... |
| |
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/
| |