Re: [rfc][patch] sched: remove smpnice

[Con Kolivas]

On Friday 10 February 2006 18:17, Andrew Morton wrote:
> "Siddha, Suresh B" <suresh.b.siddha@xxxxxxxxx> wrote:
> > On Tue, Feb 07, 2006 at 03:36:17PM -0800, Andrew Morton wrote:
> > > Suresh, Martin, Ingo, Nick and Con: please drop everything,
> > > triple-check and test this:
> > >
> > > From: Peter Williams <pwil3058@xxxxxxxxxxxxxx>
> > >
> > > This is a modified version of Con Kolivas's patch to add "nice" support
> > > to load balancing across physical CPUs on SMP systems.
> >
> > I have couple of issues with this patch.
> >
> > a) on a lightly loaded system, this will result in higher priority job
> > hopping around from one processor to another processor.. This is because
> > of the code in find_busiest_group() which assumes that SCHED_LOAD_SCALE
> > represents a unit process load and with nice_to_bias calculations this is
> > no longer true(in the presence of non nice-0 tasks)
> >
> > My testing showed that 178.galgel in SPECfp2000 is down by ~10% when run
> > with nice -20 on a 4P(8-way with HT) system compared to a nice-0 run.
> >
> > b) On a lightly loaded system, this can result in HT scheduler
> > optimizations being disabled in presence of low priority tasks... in this
> > case, they(low priority ones) can end up running on the same package,
> > even in the presence of other idle packages.. Though this is not as
> > serious as "a" above...
>
> Thanks very much for discvoring those things.
>
> That rather leaves us in a pickle wrt 2.6.16.
>
> It looks like we back out smpnice after all?

Give it the arse.

> Whatever we do, time is pressing.

We did without smp nice from 2.6.0 till 2.6.14, we can do without it again for 
some more time. Put it back in -mm for more tweaking and hopefully this added 
attention will get it more testing before being pushed.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/