From: Suren Baghdasaryan <surenb@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: akpm@linux-foundation.org, sxwjean@me.com,
xiongwei.song@linux.dev, willy@infradead.org, nathan@kernel.org,
cl@linux.com, penberg@kernel.org, rientjes@google.com,
iamjoonsoo.kim@lge.com, roman.gushchin@linux.dev,
42.hyeyoo@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH 1/1] mm, slab: move prepare_slab_obj_exts_hook under CONFIG_MEM_ALLOC_PROFILING
Date: Thu, 11 Jul 2024 11:33:04 -0700 [thread overview]
Message-ID: <CAJuCfpHDeafjETF2RhBvk1CzJ6=D6Xaur90-XUFWo9AJnF1RhQ@mail.gmail.com> (raw)
In-Reply-To: <30aa2414-3d73-4be5-adb3-10b1fc64f2a0@suse.cz>
On Thu, Jul 11, 2024 at 10:21 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 7/11/24 7:02 PM, Suren Baghdasaryan wrote:
> > The only place prepare_slab_obj_exts_hook() is currently being used is
> > from alloc_tagging_slab_alloc_hook() when CONFIG_MEM_ALLOC_PROFILING=y.
> > Move its definition under CONFIG_MEM_ALLOC_PROFILING to prevent unused
> > function warning for CONFIG_SLAB_OBJ_EXT=n case.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202407050845.zNONqauD-lkp@intel.com/
>
> Hm so that's a mainline report, but being a clang-only W=1 warning I think
> it can just wait for the merge window and no need for last-minute 6.10 fix.
Correct. I was wrong thinking that [1] caused this. The warning was
there even before but adding this into slab/for-next simply avoids
merge conflicts.
>
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > Cc: Vlastimil Babka <vbabka@suse.cz>
> > ---
> > Applied over slab/for-next because of the refactoring [1] in that branch.
>
> And thus took it there. thanks.
Thanks!
>
> >
> > [1] 302a3ea38aec ("mm, slab: move allocation tagging code in the alloc path into a hook")
> >
> > mm/slub.c | 48 +++++++++++++++++++++---------------------------
> > 1 file changed, 21 insertions(+), 27 deletions(-)
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index ce39544acf7c..829a1f08e8a2 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -2027,6 +2027,27 @@ static inline bool need_slab_obj_ext(void)
> > return false;
> > }
> >
> > +#else /* CONFIG_SLAB_OBJ_EXT */
> > +
> > +static int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
> > + gfp_t gfp, bool new_slab)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline void free_slab_obj_exts(struct slab *slab)
> > +{
> > +}
> > +
> > +static inline bool need_slab_obj_ext(void)
> > +{
> > + return false;
> > +}
> > +
> > +#endif /* CONFIG_SLAB_OBJ_EXT */
> > +
> > +#ifdef CONFIG_MEM_ALLOC_PROFILING
> > +
> > static inline struct slabobj_ext *
> > prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> > {
> > @@ -2051,33 +2072,6 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> > return slab_obj_exts(slab) + obj_to_index(s, slab, p);
> > }
> >
> > -#else /* CONFIG_SLAB_OBJ_EXT */
> > -
> > -static int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
> > - gfp_t gfp, bool new_slab)
> > -{
> > - return 0;
> > -}
> > -
> > -static inline void free_slab_obj_exts(struct slab *slab)
> > -{
> > -}
> > -
> > -static inline bool need_slab_obj_ext(void)
> > -{
> > - return false;
> > -}
> > -
> > -static inline struct slabobj_ext *
> > -prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> > -{
> > - return NULL;
> > -}
> > -
> > -#endif /* CONFIG_SLAB_OBJ_EXT */
> > -
> > -#ifdef CONFIG_MEM_ALLOC_PROFILING
> > -
> > static inline void
> > alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
> > {
> >
> > base-commit: fe4e761669ab4d8b388fdb6e9dbe9a110eed8009
>
next prev parent reply other threads:[~2024-07-11 18:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-11 17:02 Suren Baghdasaryan
2024-07-11 17:21 ` Vlastimil Babka
2024-07-11 18:33 ` Suren Baghdasaryan [this message]
2024-07-12 3:51 ` xiongwei.song
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='CAJuCfpHDeafjETF2RhBvk1CzJ6=D6Xaur90-XUFWo9AJnF1RhQ@mail.gmail.com' \
--to=surenb@google.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=nathan@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=sxwjean@me.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=xiongwei.song@linux.dev \
/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