Messages in this thread | | | Date | Thu, 9 Mar 2006 08:08:52 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Slab corruption in 2.6.16-rc5-mm2 |
| |
On Thu, 9 Mar 2006, Martin J. Bligh wrote: > > > > DEBUG_PAGEALLOC in particular is *fantastic* at making bugs hide. > > I've lost many an hour trying to pin bugs down due to that. > > Is this backwards? We're saying DEBUG_PAGEALLOC is bad?
DEBUG_PAGEALLOC is great for finding the really stupid kinds of bugs, and it's definitely worth doing every once in a while.
However, DEBUG_PAGEALLOC makes many things orders of magnitude slower, and it eats memory like mad (because it turns some slabs into whole pages - but it still doesn't help small allocation debugging that much). So unlike DEBUG_SLAB, it's not reasonable to have it on all the time.
IOW, DEBUG_SLAB is something that a distro kernel can reasonably enable for users by default (I think fedora-devel does, for example). In contrast, DEBUG_PAGEALLOC is more of a "useful for special cases" thing, where you want to validate that there's nothing _obviously_ bad going on.
> Do we NOT want to have DEBUG_SLAB and DEBUG_PAGEALLOC both enabled?
I suspect that once DEBUG_PAGEALLOC is on, whether you do DEBUG_SLAB or not is a toss-up. The interesting cases tend to be
- neither: usable for benchmarking - DEBUG_SLAB: perfectly usable for normal work - DEBUG_PAGEALLOC (with or without DEBUG_SLAB): debugging tool only
At least that's my opinion, maybe others have other experiences.
Linus - 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/
| |