Re: smp 'nice' bias support breaks scheduler behavior

From: Con Kolivas
Date: Thu Jan 26 2006 - 21:57:56 EST


On Friday 27 January 2006 13:11, Siddha, Suresh B wrote:
> On Fri, Jan 27, 2006 at 12:54:53PM +1100, Con Kolivas wrote:
> > It's not my decision to keep Peter's patch out of mainline. If you can
> > make a strong enough case for it then Linus will merge it up even though
> > it's after rc1.
>
> I don't want to push Peters patch to 2.6.16, as I haven't tested much.
>
> > Otherwise I'll let Ingo decide on whether to pull the current
> > implementation or not - you're saying that with the one thing you
> > described that misbehaves that it is doing more harm than fixing smp nice
> > handling.
>
> Are we sure that it really fixes smp nice handling? Its not just one
> scenario(bouncing processes on a lightly loaded system), I am talking
> about. Imbalance calculations will be wrong even on a completely loaded
> system.. Are you sure that there are no perf regressions with your patch..

It was extensively tested for more than 3 months in the -mm tree. Early on
there were accounting bugs in the code which I corrected and we saw no
performance regression after that across a wide range of benchmarks and
hardware configurations at the time thanks to M Bligh. (see test.kernel.org)
Some were done on the osdl (STP) test bench showing no regression as well but
the osdl infrastructure became pretty much unworkable not long after.

> Sorry for commenting on this patch so late.. I was on a very long vacation.
> I think it is safe to back that out for 2.6.16 and do more work and get it
> in 2.6.17.

Well I have no emotional investment in the code, I just want to do what's
right. In the absence of measurable throughput regressions and improvement in
smp nice handling I don't believe we should back it out.

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/