Ingo Molnar wrote:
* Martin Bligh <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
