On Mon, 2010-08-23 at 21:36 -0700, David Rientjes wrote: > On Mon, 23 Aug 2010, Matt Mackall wrote: > > > > kmalloc_node() may allocate higher order slob pages, but the __GFP_COMP > > > bit is only passed to the page allocator and not represented in the > > > tracepoint event. The bit should be passed to trace_kmalloc_node() as > > > well. > > > > > > Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx> > > > > > unsigned int order = get_order(size); > > > > > > - ret = slob_new_pages(gfp | __GFP_COMP, get_order(size), node); > > > + if (likely(order)) > > > + gfp |= __GFP_COMP; > > > > Why is it likely? I would hope that the majority of page allocations are > > in fact order 0. > > > > This code only executes when size >= PAGE_SIZE + align, so I would assume > that the vast majority of times this is actually higher order allocs > (which is probably why __GFP_COMP was implicitly added to the gfpmask in > the first place). Is there evidence to show otherwise? (peeks at code) Ok, that + should be a -. But yes, you're right, the bucket around an order-0 allocation is quite small. Acked-by: Matt Mackall <mpm@xxxxxxxxxxx> By the way, has anyone seen anything like this leak reported? /proc/slabinfo: kmalloc-32 1113344 1113344 32 128 1 : tunables 0 0 0 : slabdata 8698 8698 0 That's /proc/slabinfo on my laptop with SLUB. It looks like my last reboot popped me back to 2.6.33 so it may also be old news, but I couldn't spot any reports with Google. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>