scheduler starvation resistance patches for 2.6.16

scheduler starvation resistance patches for 2.6.16

[Mike Galbraith]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

Greetings,

Knowing that not everybody runs the latest/greatest mm kernels, I've
adapted my scheduler starvation resistance tree to virgin 2.6.16.  Those
interested will find seven patches in the attached tarball.

Test feedback much appreciated.

	-Mike

[-- Attachment #2: throttle-V25-2.6.16.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 8721 bytes --]

Re: scheduler starvation resistance patches for 2.6.16

[Willy Tarreau]

On Mon, Mar 27, 2006 at 06:35:25AM +0200, Mike Galbraith wrote:
> Greetings,
> 
> Knowing that not everybody runs the latest/greatest mm kernels, I've
> adapted my scheduler starvation resistance tree to virgin 2.6.16.  Those
> interested will find seven patches in the attached tarball.
> 
> Test feedback much appreciated.

Thanks Mike.

It will be easier to test, and I'll try to convince some people around
me to give it a try. Do you expect the exact same behaviour as in -mm ?

Regards,
Willy

Re: scheduler starvation resistance patches for 2.6.16

[Mike Galbraith]

On Tue, 2006-03-28 at 06:14 +0200, Willy Tarreau wrote:
> On Mon, Mar 27, 2006 at 06:35:25AM +0200, Mike Galbraith wrote:
> > Greetings,
> > 
> > Knowing that not everybody runs the latest/greatest mm kernels, I've
> > adapted my scheduler starvation resistance tree to virgin 2.6.16.  Those
> > interested will find seven patches in the attached tarball.
> > 
> > Test feedback much appreciated.
> 
> Thanks Mike.
> 
> It will be easier to test, and I'll try to convince some people around
> me to give it a try. Do you expect the exact same behaviour as in -mm ?

Yes, it should.

	-Mike

Re: scheduler starvation resistance patches for 2.6.16

[Al Boldi]

Mike Galbraith wrote:
> Knowing that not everybody runs the latest/greatest mm kernels, I've
> adapted my scheduler starvation resistance tree to virgin 2.6.16.

Thanks! 

> Test feedback much appreciated.

It's not bad.  w/ credit_c1/2 set to 0 results in an improvement in running 
the MESA demos  "# gears & reflect & morph3d" .

But a simple "# while :; do :; done &" (10x) makes a "# ping 10.1 -A -s8" 
choke.

Can you post a modified patch that will apply to 2.6.16-rt10 as well?

Thanks!

--
Al

Re: scheduler starvation resistance patches for 2.6.16

[Mike Galbraith]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

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.

> Can you post a modified patch that will apply to 2.6.16-rt10 as well?

Heh, it so happens I got curious about something Ingo said about PI
boosting, so made a set yesterday.  You're welcome to them, but don't
bug Ingo with any results from a tree including them.  They're not
heavily tested, but do seem to work.

	-Mike

[-- Attachment #2: throttle-V25-2.6.16-rt10.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 8821 bytes --]

Re: scheduler starvation resistance patches for 2.6.16

[Mike Galbraith]

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.

	-Mike

Re: scheduler starvation resistance patches for 2.6.16

[Al Boldi]

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.

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.

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?

Thanks!

--
Al

Re: scheduler starvation resistance patches for 2.6.16

[Mike Galbraith]

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