lkml.org 
[lkml]   [2006]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-06-01 00:39    [W:0.089 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site