From: David Rientjes <rientjes@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: cl@linux-foundation.org, penberg@cs.helsinki.fi, mpm@selenic.com,
vegard.nossum@gmail.com, dmonakhov@openvz.org,
catalin.marinas@arm.com, dfeng@redhat.com, linux-mm@kvack.org
Subject: Re: [RFC][PATCH] slab: fix caller tracking onCONFIG_OPTIMIZE_INLINING.
Date: Mon, 26 Sep 2011 18:22:40 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1109261815510.10419@chino.kir.corp.google.com> (raw)
In-Reply-To: <201109251421.BEB71358.OFOHJVMFQOFLtS@I-love.SAKURA.ne.jp>
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@kvack.org. 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@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-09-27 1:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-24 3:08 [RFC][PATCH] slab: fix caller tracking on CONFIG_OPTIMIZE_INLINING Tetsuo Handa
2011-09-24 23:00 ` David Rientjes
2011-09-25 5:21 ` [RFC][PATCH] slab: fix caller tracking onCONFIG_OPTIMIZE_INLINING Tetsuo Handa
2011-09-27 1:22 ` David Rientjes [this message]
2011-09-26 6:17 ` [RFC][PATCH] slab: fix caller tracking on CONFIG_OPTIMIZE_INLINING Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1109261815510.10419@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux-foundation.org \
--cc=dfeng@redhat.com \
--cc=dmonakhov@openvz.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox