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
On 13/02/2008, Dave Jones <davej@redhat.com> 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
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
> > 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 > >
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