rawhide & -debug

[Dave Jones]

A discussion came up at LCA about the fact that we have debugging
'always on' in rawhide kernel builds, and that it causes some people
pain, because anyone wanting to do performance testing for eg needs
to rebuild their kernel without all the debugging bits.

An idea that was tossed around was to do something similar to what
we do in release builds, and offer separate debug/nodebug builds.
But instead of how we do it in releases, do the opposite, and have
a -nodebug build, whilst keeping the regular kernel debug-turned-on
to maximise coverage testing.

Downside being that we have one extra flavor to build each day.
(more disk space used, more buildsys time etc).

Another option is that we do something like turning debug on/off
periodically (though this idea wasn't well recieved, unless it
was really easy to determine if a debug-enabled kernel was running.
Some people want to run automated perf-tests)

comments?

	Dave

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

[Christopher Brown]

On 13/02/2008, Dave Jones <davej(a)redhat.com&gt; wrote:
>  A discussion came up at LCA about the fact that we have debugging
>  'always on' in rawhide kernel builds, and that it causes some people
>  pain, because anyone wanting to do performance testing for eg needs
>  to rebuild their kernel without all the debugging bits.
>
>  An idea that was tossed around was to do something similar to what
>  we do in release builds, and offer separate debug/nodebug builds.
>  But instead of how we do it in releases, do the opposite, and have
>  a -nodebug build, whilst keeping the regular kernel debug-turned-on
>  to maximise coverage testing.
>
>  Downside being that we have one extra flavor to build each day.
>  (more disk space used, more buildsys time etc).
>
>  Another option is that we do something like turning debug on/off
>  periodically (though this idea wasn't well recieved, unless it
>  was really easy to determine if a debug-enabled kernel was running.
>  Some people want to run automated perf-tests)
>
>  comments? 
I'm a newbie in this but http://fedoraproject.org/wiki/KernelCommonProblems

indicates slab debugging can be disabled using:

slub_debug=-

Is this true and if so does this affect things at all? The barrier to
getting a debug variant is pretty low so I'm really not fussed either
way.

Cheers

-- 
Christopher Brown

http://www.chruz.com

[Dave Jones]

On Wed, Feb 13, 2008 at 11:53:34PM +0000, Christopher Brown wrote:

>  I'm a newbie in this but
> http://fedoraproject.org/wiki/KernelCommonProblems
>  
>  indicates slab debugging can be disabled using:
>  
>  slub_debug=-
>  
>  Is this true and if so does this affect things at all? The barrier to
>  getting a debug variant is pretty low so I'm really not fussed either
>  way. 
This only recently became a runtime thing, but there's still a bunch
of performance impacting options that aren't runtime selectable
(like lockdep for example).

	Dave

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

[Prarit Bhargava]

>  An idea that was tossed around was to do something similar to what
>  we do in release builds, and offer separate debug/nodebug builds.
>  But instead of how we do it in releases, do the opposite, and have
>  a -nodebug build, whilst keeping the regular kernel debug-turned-on
>  to maximise coverage testing. 
Personally, I'd like to see this but let's face it, we always will have 
situations where changing the timing of the kernel execution causes bugs 
to come-and-go.  I guess there may have to be a certain amount of debug 
we have to live with.

P.
>  	Dave
>
>

[dexter]

On Wed February 13 2008 23:29:31 Dave Jones wrote:
>  comments?
>  
1)I hate debug.
2)if the kernel is in constant debug, on release day this is an untested 
situation so why not remove debug for releases (alpha,beta,test-n whatever 
the new scheme is these days) and switch it back on for general rawhide 
consumption.
3)with all the recent spec file changes can we have a --without-debug rebuild 
option to ease the pain.
4)I hate debug.  

...dex