On Fri, Nov 30, 2007 at 10:14:18AM +0100, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > > plus, and this is a slob question i guess, how come we drop into > > > clear_highpage() for a kzalloc()?? > > > > Good question. Looks like kzalloc switched from doing a memset to > > passing a GFP_ZERO flag down to kmalloc. Slob didn't get completely > > updated to reflect this, so it blindly propagates the flag onto > > __alloc_pages and does a harmless double-clear. > > > > Someone should remind us what the point of moving the kzalloc memset > > down into the allocators was. We now have all three allocators doing: > > > > if (unlikely((flags & __GFP_ZERO) && ptr)) > > memset(ptr, 0, obj_size(cachep)); > > > > and needing to mask flags before passing them to page allocators, > > which hardly seems better than kzalloc unconditionally doing the > > memset. Wouldn't it be better/faster/smaller to make kzalloc a > > non-inline? > > > > Slob also has a nice second path for large kmallocs where it just > > calls the page allocator directly which also needs this treatment. > > Which does the right thing with non-highmem systems, but can hit this > > bug otherwise. > > > > Below is a totally untested patch. Alternately, we could simply tweak > > clear_highpage to remove the limitation, but that would leave slob > > doing an extra clear. > > ok, this fixes the debug warning. >
But the question remains: is this the right fix? The commit in question is here: http://www.kernel.org/hg/linux-2.6/rev/13683609d67a Christoph, remind us what's the upside here? It seems to me it would be better to have separate non-inline kzalloc and kcalloc functions that did the memset instead. Another smaller open question is whether we want to remove the in_interrupt restriction from clear_pagehigh. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/