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 ;-)