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

[Peter Williams <pwil3058@bigpond.net.au>]

Con Kolivas wrote:
> On Saturday 28 January 2006 07:06, MIke Galbraith wrote:
>
> > What do you think of the below as an evaluation patch?  It leaves the
> > bits I'd really like to change (INTERACTIVE_SLEEP() for one), so it can
> > be switched on and off for easy comparison and regression testing.
> >
> > I really didn't want to add more to the task struct, but after trying
> > different things, a timeout was the most effective means of keeping the
> > nice burst aspect of the interactivity logic but still make sure that a
> > burst doesn't turn into starvation.
> >
> > The workings are dirt simple just as before.  The goal is to keep
> > sleep_avg and slice_avg balanced.  When an imbalance starts, immediately
> > cut off interactive bonus points.  If the imbalance doesn't correct
> > itself through normal sleep_avg usage, we'll soon hit the (1 dynamic
> > prio) trigger point, which starts a countdown toward active
> > intervention.  The default setting is that a task can run at higher
> > dynamic priority than it's cpu usage can justify for 5 seconds.  After
> > than, we start trying to work off the deficit, and if we don't succeeded
> > within another second (ie it was a big deficit), we demote the offender
> > to the rank his cpu usage indicates.
> >
> > The strategy works well enough to take the wind out of irman2's sails,
> > and interactive tasks can still do a nice reasonable burst of activity
> > without being evicted.  Down side to starvation control is that X is
> > sometimes a serious cpu user, and _can_ end up in the expired array (not
> > nice under load).  I personally don't think that's a show stopper
> > though... all you have to do is tell the scheduler that what it already
> > noticed, that X is a piggy, but an OK piggy by renicing it. It becomes
> > immune from active throttling, and all is well.  I know that's not going
> > to be popular, but you just can't let X have free rein without leaving
> > the barn door wide open.  (maybe that switch should stay since the
> > majority of boxen are workstations, and default to off?).
>
>
> Sounds good but I have to disagree on the X renice thing. It's not that I have 
> a religious objection to renicing things. The problem is that our mainline 
> scheduler determines latency also by nice level. This means that if you 
> -renice a bursty cpu hog like X, then audio applications will fail unless 
> they too are reniced. Try it on your patch.

On the other hand, if X were reniced it would be possible to make the 
interactive bonus mechanism more strict on what it considers to be 
interactive.  As I see it the main reason that non interactive sleeps 
get any consideration at all in determining whether a task is 
interactive is to make sure that X is classified interactive.

One of the things that I've noticed about the X server (with 
instrumented systems) is the its proportion of interruptible sleeps to 
total sleeps goes down when it becomes CPU intensive.  This is because 
the high CPU usage is usually related to screen updates (e.g. try "ls -R 
/" in an xterm or similar) and not keyboard or mouse input.  This means 
that during these periods the X server would lose most of its 
interactive bonus and just rely on its niceness allowing genuine 
interactive tasks to pip it (provided that X's nice value is 
sufficiently small e.g. 5).

Of course, for this to work all of the instances where interruptible 
sleeps aren't interactive would need to be labelled TASK_NONINTERACTIVE 
which would be a big job.

Anyway just my 2c worth.

Peter
--
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/