Re: [PATCH] O6int for interactivity

From: Mike Galbraith (
Date: Mon Jul 21 2003 - 00:36:31 EST

At 05:21 PM 7/20/2003 -0700, Davide Libenzi wrote:
>On Sat, 19 Jul 2003, Mike Galbraith wrote:
> > >Everything that will make the scheduler to say "ok, I gave enough time to
> > >interactive tasks, now I'm really going to spin one from the masses" will
> > >work. Having a clean solution would not be an option here.
> >
> > ... just as soon as I get my decidedly unclean work-around functioning at
> > least as well as it did for plain old irman. irman2 is _much_ more evil
> > than irman ever was (wow, good job!). I thought it'd be a half an hour
> > tops. This little bugger shows active starvation, expired starvation,
> > priority inflation, _and_ interactive starvation (i have to keep inventing
> > new terms to describe things i see.. jeez this is a good testcase).
>Yes, the problem is not only the expired tasks starvation. Anything in
>the active array that reside underneath the lower priority value of the
>range irman2 tasks oscillate inbetween, will experience a "CPU time eclipse".
>And you do not even need a smoked glass to look at it :)

Here there's no oscillation that I can see. It climbs steadily to prio 16
and stays there forever, with the hog running down at the bottom. I did a
quick requirement that a non-interactive task must run every HZ ticks at
least, with a sliding "select non-interactive" window staying open for
HZ/10 ticks, and retrieving an expired task if necessary instead of
expiring interactive tasks (or forcing the array switch) thinking it'd be

Wrong answer. For most things, it would be good enough I think, but with
the hog being part of irman2, I have to not only pull from the expired
array if no non-interactive task is available, I have to always pull once
the deadline is hit. I'm also going to have to put another check for queue
runtime to beat the darn thing. I ran irman2 with a bonnie -s 300 and a
kernel compile... After a half an hour, the compile was making steady (but
too slow because the irman2 periodic cpu hog was getting too much of what
gcc was intended to get;) progress, but the poor bonnie was starving at
prio 17. A sleep_avg vs cpu%*100 sanity check will help that, but not cure.

All this to avoid the pain (agony actually) of an array switch.


(someone should wrap me upside the head with a clue-x-4. this darn thing
shouldn't be worth more than 10 lines of ugliness. i'm obviously past
that... and headed toward the twilight-zone at warp 9. wheee;)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:42 EST