Messages in this thread | | | Date | Wed, 31 May 2006 15:36:43 -0700 | From | Martin Bligh <> | Subject | Re: 2.6.17-rc5-mm1 |
| |
Ingo Molnar wrote: > * Martin Bligh <mbligh@google.com> wrote: > > >>>>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. >> >>The "no idea" is hardly reassuring ;-) >>The latter point is definitely valid though, it's not an isolated issue. > > >>Adding new runs is easy. Changing the harness is hard ;-) > > > ok. How about a CONFIG_DEBUG_NO_OVERHEAD option, that would default to > disabled but which you could set to y. Then we could make all the more > expensive debug options: > > default y if !CONFIG_DEBUG_NO_OVERHEAD > > this would still mean you'd have to turn off CONFIG_DEBUG_NO_OVERHEAD, > but it would be automatically maintainable for you after that initial > effort, and we'd be careful to always flag new debugging options with > this flag, if they are expensive. And initially i'd define "expensive" > as "anything that adds runtime overhead". > > would this be acceptable to you?
Sure, makes sense. I don't care which way up it is, ie CONFIG_DEBUG_OVERHEAD vs CONFIG_DEBUG_NO_OVERHEAD, as long as it's easily separable.
There's probably other debug stuff we can turn on too, if we do that.
M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |