On Sun, 25 Sep 2011, Tetsuo Handa wrote: > > So this is going against the inlining algorithms in gcc 4.x which will > > make the kernel image significantly larger even though there seems to be > > no benefit unless you have CONFIG_DEBUG_SLAB_LEAK, although this patch > > changes behavior for every system running CONFIG_SLAB with tracing > > support. > > If use of address of kzalloc() itself is fine for tracing functionality, we > don't need to force tracing functionality to use caller address of kzalloc(). > > I merely want /proc/slab_allocators to print caller address of kzalloc() rather > than kzalloc() address itself. > Yeah, I understand the intent of the patch, but I don't think we need to force inlining in all the conditions that you specified it. We know that CONFIG_DEBUG_SLAB_LEAK kernels aren't performance critical and it seems reasonable that they aren't image size critical either, but we certainly don't need this for kernels configured for SLUB or for SLAB kernels with tracing support and not CONFIG_DEBUG_SLAB_LEAK. The "caller" formal to cache_alloc_debugcheck_after() wants the true caller of the allocation for CONFIG_DEBUG_SLAB_LEAK. kmalloc() is already __always_inline, so just define slabtrace_inline to be __always_inline for CONFIG_DEBUG_SLAB_LEAK? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>