Re: [SCHED] wrong priority calc - SIMPLE test case

[Mike Galbraith <efault@gmx.de>]

At 10:15 AM 1/2/2006 +0100, Mike Galbraith wrote:
> At 12:39 PM 1/1/2006 +0100, Paolo Ornati wrote:
> > On Sat, 31 Dec 2005 17:37:11 +0100
> > Mike Galbraith <efault@gmx.de> wrote:
> >
> > > Strange.  Using the exact same arguments, I do see some odd bouncing up to
> > > high priorities, but they spend the vast majority of their time down 
> > at 25.
> >
> > Mmmm... to make it more easly reproducible I've enlarged the sleep time
> > (1 microsecond is likely to be rounded too much and give different
> > results on different hardware/kernel/config...).
> >
> > Compile this _without_ optimizations and try again:
>
> <snip>
>
> > Try different values: 1000, 2000, 3000 ... are you able to reproduce it
> > now?
>
> Yeah.  One instance running has to sustain roughly _95%_ cpu before it's 
> classified as a cpu piggy.  Not good.
>
> > If yes, try to start 2 of them with something like this:
> >
> > "./a.out 3000 & ./a.out 3161"
> >
> > so they are NOT syncronized and they use almost all the CPU time:
> >
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >  5582 paolo     16   0  2396  320  252 S 45.7  0.1   0:05.52 a.out
> >  5583 paolo     15   0  2392  320  252 S 45.7  0.1   0:05.49 a.out
> >
> > This is the bad situation I hate: some cpu-eaters that eat all the CPU
> > time BUT have a really good priority only because they sleeps a bit.
>
> Yup, your proggy fools the interactivity estimator quite well.  This 
> problem was addressed a long time ago, and thought to be more or less 
> cured.  Guess not.

Care to try an experiment?  I'd be very interested in knowing if the 
attached patch cures the real-life problem you were investigating.

It attempts to catch tasks which the interactivity logic has misidentified, 
and "pull their plug".  It maintains a running plausibility check 
(slice_avg) against sleep_avg, and if a sustained disparity appears, cuts 
off a cpu burning task's supply of bonus points such that it has to "run on 
battery" until the disparity decreases to within acceptable limits.

Obviously, anything that affects fairness _will_ affect interactivity to 
some degree. This simple bolt-on throttle has delayed initiation and 
accelerated release in the hopes of keeping it's impact acceptable.  After 
some initial testing, It doesn't _seem_ to suck.

        -Mike

Attachment: sched_throttle
Description: Binary data