Re: [PATCH] O6int for interactivity

[Mike Galbraith <efault@gmx.de>]

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 
enough.

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.

         -Mike

(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;)