Re: [RFC 1/4] CONFIG_STABLE: Define it

[Christoph Lameter <clameter@sgi.com>]

On Fri, 1 Jun 2007, Dave Jones wrote:

>  > Disabling SLUB_DEBUG should only be done for embedded systems. That is why 
>  > the option is in CONFIG_EMBEDDED.
> 
> Something I'd really love to have is a CONFIG option to decide if
> slub_debug is set or not by default.  The reasoning behind this is that during
> development of each Fedora release, I used to leave SLAB_DEBUG=y for
> months on end and catch all kinds of nasties.

So slub_debug as a boot parameter is not enough.

> Now that I've switched it over to using slub, I ended up adding the
> ugly patch below, because otherwise, no-one would ever run with
> slub_debug and we'd miss out on all those lovely bugs.

Oh. No worry. By default slub puts its free pointer in the most dangerous 
area. In my experience it will bug immediately if there is something 
wrong. The mode of operations that I had in mind for development was to 
run until we crash somewhere. Then reboot with slub_debug to get the 
lovely report on who did it.

> (I have 'make release' and 'make debug' targets which enable/disable
>  this [and other] patches in the Fedora kernel).
> 
> (Patch for illustration only, obviously not for applying).

Hummm..... I need to think about this one.
 
> Unless someone beats me to it, I'll hack up a CONFIG option around
> this. Having that turned on if !CONFIG_STABLE would also be a win I think.

Doing so will impair performance testing. Memory use will be changed due 
to the growth of all the objects etc etc. Generally I think running 
with slub_debug by default is overkill. 

Having said that you can do even more if you would run

slabinfo -v

to validate object from cron. That way you can check up on all slab 
objects.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/