[Ksummit-2012-discuss] debug options.

Dave Jones davej at redhat.com
Wed Jun 27 16:35:12 UTC 2012


On Wed, Jun 27, 2012 at 06:19:27PM +0200, Jan Kara wrote:
 > On Wed 27-06-12 11:53:47, Dave Jones wrote:
 > > Something else I'd like to talk about.
 > > 
 > > We have boatloads of config options for debugging features.
 > > Sometimes it feels like hardly anyone is using them.
 > > 
 >   Well, there are two sides to this - when you run with debug options you
 > may hit different code paths than without them. Thus you won't see bugs
 > people will see without debug options. Especially if you care about things
 > like lock contention or other performance issues.

absolutely, and performance regression testing is something important to care about too.
But I get the impression that the balance between "whoa, look how fast
we can go" and "let's make sure this does the right thing" is currently tilted a
little too far in the wrong direction. I'd be curious to see a show of hands at
ksummit of how many people regulary test with various options.

 > BTW: I do test my trees with lockdep and slab debug enabled...

excellent!

 > For example for radix trees there is a reasonable test harness in
 > userspace (Andrew is maintaining it). I'm not sure if that bug got though
 > simply because noone run the tests or if the test harness didn't check for
 > the right thing...
 > 
 > That radix tree tests take some time to run (like tens of seconds) so I'm
 > sceptical someone would enable them in kernel config except really
 > determined individuals. But including the tests in kernel tree so that it's
 > easier for determined individuals (and developers changing radix tree code)
 > to run them would be a good thing IMHO.

indeed, I was completely unaware that even existed for eg.
We've just begun a testing initiative in Fedora that ultimately will run a bunch
of tests like this for every built kernel. It's very early on, and needs a lot
more work, but this sort of thing is exactly what we hope to add.

	Dave



More information about the Ksummit-2012-discuss mailing list