[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74d14df1-faa7-dc12-d406-ba038682e134@suse.cz>
Date: Wed, 23 Nov 2022 10:21:03 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Feng Tang <feng.tang@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
Andrey Konovalov <andreyknvl@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Andrey Ryabinin <ryabinin.a.a@...il.com>,
Alexander Potapenko <glider@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
linux-mm@...ck.org, kasan-dev@...glegroups.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro
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@...el.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
> */
Powered by blists - more mailing lists