All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Feng Tang <feng.tang@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	linux-mm@kvack.org, kasan-dev@googlegroups.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro
Date: Wed, 23 Nov 2022 10:21:03 +0100	[thread overview]
Message-ID: <74d14df1-faa7-dc12-d406-ba038682e134@suse.cz> (raw)
In-Reply-To: <Y3xeYF5NipSbBFSZ@feng-clx>

On 11/22/22 06:30, Feng Tang wrote:
> On Mon, Nov 21, 2022 at 12:19:38PM -0800, Andrew Morton wrote:
>> On Mon, 21 Nov 2022 21:50:23 +0800 Feng Tang <feng.tang@intel.com> wrote:
>> 
>> > +#ifndef CONFIG_SLOB
>> > +#define is_kmalloc_cache(s) ((s)->flags & SLAB_KMALLOC)
>> > +#else
>> > +#define is_kmalloc_cache(s) (false)
>> > +#endif
>> 
>> Could be implemented as a static inline C function, yes?
> 
> Right, I also did try inline function first, and met compilation error: 
> 
> "
> ./include/linux/slab.h: In function ‘is_kmalloc_cache’:
> ./include/linux/slab.h:159:18: error: invalid use of undefined type ‘struct kmem_cache’
>   159 |         return (s->flags & SLAB_KMALLOC);
>       |                  ^~
> "
> 
> The reason is 'struct kmem_cache' definition for slab/slub/slob sit
> separately in slab_def.h, slub_def.h and mm/slab.h, and they are not
> included in this 'include/linux/slab.h'. So I chose the macro way.

You could try mm/slab.h instead, below the slub_def.h includes there.
is_kmalloc_cache(s) shouldn't have random consumers in the kernel anyway.
It's fine if kasan includes it, as it's intertwined with slab a lot anyway.

> Btw, I've worked on some patches related with sl[auo]b recently, and
> really felt the pain when dealing with 3 allocators, on both reading
> code and writing patches. And I really like the idea of fading away
> SLOB as the first step :)

Can't agree more :)

>> If so, that's always best.  For (silly) example, consider the behaviour
>> of
>> 
>> 	x = is_kmalloc_cache(s++);
>> 
>> with and without CONFIG_SLOB.
> 
> Another solution I can think of is putting the implementation into
> slab_common.c, like the below?

The overhead of function call between compilation units (sans LTO) is not
worth it.

> Thanks,
> Feng
> 
> ---
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 067f0e80be9e..e4fcdbfb3477 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -149,6 +149,17 @@
>  
>  struct list_lru;
>  struct mem_cgroup;
> +
> +#ifndef CONFIG_SLOB
> +extern bool is_kmalloc_cache(struct kmem_cache *s);
> +#else
> +static inline bool is_kmalloc_cache(struct kmem_cache *s)
> +{
> +	return false;
> +}
> +#endif
> +
>  /*
>   * struct kmem_cache related prototypes
>   */
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index a5480d67f391..860e804b7c0a 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -77,6 +77,13 @@ __setup_param("slub_merge", slub_merge, setup_slab_merge, 0);
>  __setup("slab_nomerge", setup_slab_nomerge);
>  __setup("slab_merge", setup_slab_merge);
>  
> +#ifndef CONFIG_SLOB
> +bool is_kmalloc_cache(struct kmem_cache *s)
> +{
> +	return (s->flags & SLAB_KMALLOC);
> +}
> +#endif
> +
>  /*
>   * Determine the size of a slab object
>   */


  parent reply	other threads:[~2022-11-23  9:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 13:50 [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro Feng Tang
2022-11-21 13:50 ` [PATCH -next 2/2] mm/kasan: simplify is_kmalloc check Feng Tang
2022-11-21 14:13   ` Feng Tang
2022-11-21 15:15   ` Andrey Konovalov
2022-11-22  6:53     ` Feng Tang
2022-11-22  9:57       ` Andrey Konovalov
2022-11-21 20:19 ` [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro Andrew Morton
2022-11-22  5:30   ` Feng Tang
2022-11-22 23:17     ` Andrew Morton
2022-11-23  9:21     ` Vlastimil Babka [this message]
2022-11-23 12:17       ` Feng Tang

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=74d14df1-faa7-dc12-d406-ba038682e134@suse.cz \
    --to=vbabka@suse.cz \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=cl@linux.com \
    --cc=dvyukov@google.com \
    --cc=feng.tang@intel.com \
    --cc=glider@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kasan-dev@googlegroups.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=ryabinin.a.a@gmail.com \
    --cc=vincenzo.frascino@arm.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 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.