Messages in this thread | | | Date | Fri, 30 Nov 2007 16:35:37 -0600 | From | Matt Mackall <> | Subject | Re: [bug] SLOB, tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() |
| |
On Fri, Nov 30, 2007 at 10:14:18AM +0100, Ingo Molnar wrote: > > * Matt Mackall <mpm@selenic.com> 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 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/
| |