Re: 2.6.17-rc5-mm1

[Ingo Molnar <mingo@elte.hu>]

* Martin J. Bligh <mbligh@mbligh.org> wrote:

> >but ... i fixed the performance problem that caused the previous 
> >DEBUG_MUTEXES scalability problems. (there's no global mutex list 
> >anymore) We also default to e.g. DEBUG_SLAB which is alot more costly.
> 
> OK. So what's the perf impact of the new version on a 32 cpu machine? 
> ;-) Maybe it's fine, maybe it's not.

no idea, but it shouldnt be nearly as bad as say SLAB_DEBUG.

> >i'm wondering, why doesnt your config have DEBUG_MUTEXES disabled? Then 
> >'make oldconfig' would pick it up automatically.
> 
> Because it builds off the same config file all the time. It was 
> created before CONFIG_MUTEXES existed ... creating a situation where 
> we have to explicitly disable new options all the time becomes a 
> maintainance nightmare ;-(

hm, why? Dont you disable DEBUG_SLAB? [that's a default y option too, 
and in your config it's disabled]

a oneliner script:

 sed -i 's/CONFIG_MUTEX_DEBUGGING=y/# CONFIG_MUTEX_DEBUGGING is not set'

ought to do it, unless i'm missing something.

Really, there's an unfortunate friction of interests here:

on one side, the -mm kernel is about showcasing new code and finding 
bugs in them as fast as possible. Having new debugging options enabled 
by default is an important part of the testing effort. Users will care 
more about having no crashes than about having 0.5% more performance in 
select benchmarks.

on the other side, you obviously dont want a 0.5% overhead for select 
benchmarks, as that would mess up the history! A very fair and valid 
position too.

but one side has to give, we cant have both.

> If we don't want to do performance regression checking on -mm, that's 
> fine, but I thought it was useful (has caught several things already).

please dont misunderstand my position as being against your efforts - to 
the contrary, your performance regression testing has proven to be 
valuable numerous times! But you are a single intelligent person whom i 
can possibly talk into adding some scripting to ensure that certain 
options stay off in the .config - but i cannot cat-herd the many -mm 
testers on the other hand to all enable the debug options ;-) So i'm 
kind of forced trying to convince you - i cannot convince the basic 
human testing nature of keeping the defaults ;-)

	Ingo