Re: scheduler starvation resistance patches for 2.6.16

[Mike Galbraith <efault@gmx.de>]

On Tue, 2006-03-28 at 23:01 +0300, Al Boldi wrote:
> Mike Galbraith wrote:
> > On Tue, 2006-03-28 at 07:10 +0200, Mike Galbraith wrote:
> > > On Mon, 2006-03-27 at 21:36 +0300, Al Boldi wrote:
> > > > It's not bad.  w/ credit_c1/2 set to 0 results in an improvement in
> > > > running the MESA demos  "# gears & reflect & morph3d" .
> > >
> > > Hmm.  That's unexpected.
> > >
> > > > But a simple "# while :; do :; done &" (10x) makes a "# ping 10.1 -A
> > > > -s8" choke.
> > >
> > > Ouch, so is that.  But thanks, testcases are great.  I'll look into it.
> >
> > OK, this has nothing to do with my patches.  The same slowdown happens
> > with a stock kernel when running a few pure cpu hogs.  I suspect it has
> > to do with softirqd, but am still investigating.
> 
> I think so too.

(suspicion led to wild goose chase)

> I played with some numbers inside sched.c.  Raising the MIN_TIMESLICE from 1 
> to between 10-100  affects interactivity positively, although it does not 
> fix it entirely.

After some fiddling with it, looks to me like it's just a combination of
EXPIRED_STARVING(rq) doing it's thing, which in turn causes (if you're
running kde at least) your terminal to not be able to keep up, which
makes it lose priority due to burning more cpu trying to catch up.

Try this.  Using virgin 2.6.16, disable EXPIRED_STARVING(rq), and start
your ping -A without any cpu hogs.  If you're running KDE, you'll notice
that the konsole priority where ping is running remains forever highly
interactive.  Enable EXPIRED_STARVING(rq) and repeat.  Just from the
scrolling, being bumped into the expired array will cause konsole to
lose priority because of increased cpu usage trying to catch up.

There is a price to be paid for starvation prevention.  You can choose
when it's paid, and in what sized installments, but pay you will :-/

> It does look like there is an underlying problem (locking?) that may be 
> worked-around by tuning the scheduler to some extent.
> 
> Also, MAX_TIMESLICE = 800 seems a bit high.  Can this be lowered?

The round-robin logic prevents this from being a problem.

	-Mike