handling a 'debug' or 'development' setting

[Dave Jones]

On Tue, Jul 15, 2008 at 06:24:27PM -0400, Bill Nottingham wrote:
 > In initscripts recently, we added code that would conditionally
 > enable two forms of malloc debugging. [1]  While this build was
 > disabled shortly after it hit the build system (because it
 > broke the build system [2]), it raised a more general issue.
 > 
 > We should have a generic framework for running in a 'debug'
 > or 'development' mode that does extra debugging at the sake
 > of some minimal amount of performance.
 > 
 > For example, right now in the rawhide kernel we enable various
 > debug options, which are then disabled when we do final builds
 > for a release. Wouldn't it be better if these could be switched
 > on somehow at runtime based on configuration?

For the kernel options, the problem is that most of the costly ones
aren't runtime switchable, and can't be made to do so.
Their cost comes from the growth of various data structures, so
we need to copy more data around etc. (as an example, page structs
almost double in size with lockdep enabled on 32bit).

Even if we took all the options which /are/ runtime switchable,
put them under your config management proposal, and then turned 
them off, the cost of the stuff that's still enabled is pretty
dramatic.  (Especially things like PAGEALLOC_DEBUG)

I don't really have much of an opinion on whether one way is better
than the other, but I want people to realise that turning off
the knobs that are turnable isn't going to be the silver bullet
to performance.

	Dave

-- 
http://www.codemonkey.org.uk