From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Marco Elver <elver@google.com>,
Matthew WilCox <willy@infradead.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 08/23] mm/slab_common: make kmalloc_large_node() consistent with kmalloc_large()
Date: Thu, 28 Apr 2022 15:35:42 +0900 [thread overview]
Message-ID: <Ymo1vi0JrGVxaQB1@hyeyoo> (raw)
In-Reply-To: <37811df5-b0f5-355b-41cf-2e491fb3cd6c@suse.cz>
On Tue, Apr 26, 2022 at 07:15:06PM +0200, Vlastimil Babka wrote:
> On 4/14/22 10:57, Hyeonggon Yoo wrote:
> > Move tracepoints into kmalloc_large_node() and add missing flag fix code.
> >
> > Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
>
Hello Vlastimil, thanks for review! ;-)
> Hm so there's a problem with the tracepoint's caller.
>
> kmalloc_large() is only called from kmalloc() which is an inline thus the
> callsite of kmalloc() calls directly kmalloc_large().
> So when kmalloc_large() does "trace_kmalloc(_RET_IP_, ...)" the _RET_IP_ is the
> callsite of kmalloc(), which is what we want.
kmalloc_large() had the exact problem before my series when called from __kmalloc().
On top of current slab/for-next:
[000] ..... 43.172574: kmalloc: call_site=__kmalloc+0x2aa/0x300 ptr=ffff88e2183a0000 bytes_req=12368 bytes_alloc=16384 gfp_flags=GFP_KERNEL
Considering different usecases of kmalloc_large_node() (called from kmalloc_node() or __kmalloc_node()),
I think we need trace/notrace version of kmalloc_large_node().
>
> But with kmalloc_large_node()...
>
> > ---
> > mm/slab_common.c | 6 ++++++
> > mm/slub.c | 22 ++++------------------
> > 2 files changed, 10 insertions(+), 18 deletions(-)
> >
> > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > index e72089515030..cf17be8cd9ad 100644
> > --- a/mm/slab_common.c
> > +++ b/mm/slab_common.c
> > @@ -955,6 +955,9 @@ void *kmalloc_large_node(size_t size, gfp_t flags, int node)
> > void *ptr = NULL;
> > unsigned int order = get_order(size);
> >
> > + if (unlikely(flags & GFP_SLAB_BUG_MASK))
> > + flags = kmalloc_fix_flags(flags);
> > +
> > flags |= __GFP_COMP;
> > page = alloc_pages_node(node, flags, order);
> > if (page) {
> > @@ -966,6 +969,9 @@ void *kmalloc_large_node(size_t size, gfp_t flags, int node)
> > ptr = kasan_kmalloc_large(ptr, size, flags);
> > /* As ptr might get tagged, call kmemleak hook after KASAN. */
> > kmemleak_alloc(ptr, size, 1, flags);
> > + trace_kmalloc_node(_RET_IP_, ptr,
> > + size, PAGE_SIZE << order,
> > + flags, node);
>
> ... the _RET_IP_ here would be __kmalloc_node() which is not useful.
>
> > return ptr;
> > }
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 640712706f2b..f10a892f1772 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -4396,15 +4396,8 @@ void *__kmalloc_node(size_t size, gfp_t flags, int node)
> > struct kmem_cache *s;
> > void *ret;
> >
> > - if (unlikely(size > KMALLOC_MAX_CACHE_SIZE)) {
> > - ret = kmalloc_large_node(size, flags, node);
> > -
> > - trace_kmalloc_node(_RET_IP_, ret,
> > - size, PAGE_SIZE << get_order(size),
> > - flags, node);
>
> Here it was OK because __kmalloc_node is expanded from something inline
> coming from slab.h.
>
> > -
> > - return ret;
> > - }
> > + if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
> > + return kmalloc_large_node(size, flags, node);
> >
> > s = kmalloc_slab(size, flags);
> >
> > @@ -4861,15 +4854,8 @@ void *__kmalloc_node_track_caller(size_t size, gfp_t gfpflags,
> > struct kmem_cache *s;
> > void *ret;
> >
> > - if (unlikely(size > KMALLOC_MAX_CACHE_SIZE)) {
> > - ret = kmalloc_large_node(size, gfpflags, node);
> > -
> > - trace_kmalloc_node(caller, ret,
> > - size, PAGE_SIZE << get_order(size),
> > - gfpflags, node);
> > -
> > - return ret;
> > - }
> > + if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
> > + return kmalloc_large_node(size, gfpflags, node);
>
> And here it even forgets the 'caller'.
>
Thanks for catching this.
I think notrace version + tracepoint would fit here.
> >
> > s = kmalloc_slab(size, gfpflags);
> >
>
--
Thanks,
Hyeonggon
next prev parent reply other threads:[~2022-04-28 6:35 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 8:57 [PATCH v2 00/23] common kmalloc for SLUB and SLAB v2 Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 01/23] mm/slab: move NUMA-related code to __do_cache_alloc() Hyeonggon Yoo
2022-04-22 18:04 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 02/23] mm/slab: cleanup slab_alloc() and slab_alloc_node() Hyeonggon Yoo
2022-04-25 14:05 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 03/23] mm/slab_common: remove CONFIG_NUMA ifdefs for common kmalloc functions Hyeonggon Yoo
2022-04-25 14:41 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 04/23] mm/slab_common: cleanup kmalloc_track_caller() Hyeonggon Yoo
2022-04-25 15:05 ` Vlastimil Babka
2022-04-26 15:49 ` Vlastimil Babka
2022-04-30 11:44 ` Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 05/23] mm/slab_common: cleanup __kmalloc() Hyeonggon Yoo
2022-04-26 16:02 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 06/23] mm/sl[auo]b: fold kmalloc_order_trace() into kmalloc_large() Hyeonggon Yoo
2022-04-26 16:09 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 07/23] mm/slub: move kmalloc_large_node() to slab_common.c Hyeonggon Yoo
2022-04-26 16:13 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 08/23] mm/slab_common: make kmalloc_large_node() consistent with kmalloc_large() Hyeonggon Yoo
2022-04-26 17:15 ` Vlastimil Babka
2022-04-28 6:35 ` Hyeonggon Yoo [this message]
2022-04-14 8:57 ` [PATCH v2 09/23] mm/slab_common: cleanup kmalloc_large() Hyeonggon Yoo
2022-04-26 17:18 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 10/23] mm/slab_common: cleanup kmem_cache_alloc{,node,lru} Hyeonggon Yoo
2022-04-26 18:01 ` Vlastimil Babka
2022-04-30 11:48 ` Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 11/23] mm/slab_common: kmalloc_node: pass large requests to page allocator Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 12/23] mm/slab_common: cleanup kmalloc() Hyeonggon Yoo
2022-04-26 18:00 ` Joe Perches
2022-04-28 11:30 ` Hyeonggon Yoo
2022-04-27 7:50 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 13/23] mm/slab: kmalloc: pass requests larger than order-1 page to page allocator Hyeonggon Yoo
2022-04-27 8:10 ` Vlastimil Babka
2022-04-30 11:50 ` Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 14/23] mm/slab_common: print cache name in tracepoints Hyeonggon Yoo
2022-04-29 14:05 ` Vlastimil Babka
2022-04-30 14:06 ` Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 15/23] mm/slab_common: use same tracepoint in kmalloc and normal caches Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 16/23] mm/slab_common: rename tracepoint Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 17/23] mm/slab_common: implement __kmem_cache_free() Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 18/23] mm/sl[au]b: generalize kmalloc subsystem Hyeonggon Yoo
2022-04-29 14:30 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 19/23] mm/slab_common: add kasan_kmalloc() in __kmalloc_node_track_caller() Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 20/23] mm/slab_common: factor out __do_kmalloc_node() Hyeonggon Yoo
2022-04-14 11:45 ` Hyeonggon Yoo
2022-04-29 14:48 ` Vlastimil Babka
2022-04-14 8:57 ` [PATCH v2 21/23] mm/sl[au]b: remove kmem_cache_alloc_node_trace() Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 22/23] mm/sl[auo]b: move definition of __ksize() to mm/slab.h Hyeonggon Yoo
2022-04-14 8:57 ` [PATCH v2 23/23] mm/sl[au]b: check if large object is valid in __ksize() Hyeonggon Yoo
2022-04-14 9:58 ` Christoph Lameter
2022-04-14 11:46 ` Hyeonggon Yoo
2022-04-14 12:36 ` [PATCH v2 00/23] common kmalloc for SLUB and SLAB v2 Hyeonggon Yoo
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=Ymo1vi0JrGVxaQB1@hyeyoo \
--to=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=elver@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.