[PATCH 1/3] mm, slab: deprecate SLAB_MEM_SPREAD flag

[Vlastimil Babka]

The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
removed. SLUB instead relies on the page allocator's NUMA policies.
Change the flag's value to 0 to free up the value it had, and mark it
for full removal once all users are gone.

Reported-by: Steven Rostedt <ros...@goodmis.org>
Closes: https://lore.kernel.org/all/20240131172...@gandalf.local.home/
Signed-off-by: Vlastimil Babka <vba...@suse.cz>
---
include/linux/slab.h | 5 +++--
mm/slab.h | 1 -
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/slab.h b/include/linux/slab.h
index b5f5ee8308d0..6252f44115c2 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -96,8 +96,6 @@
*/
/* Defer freeing slabs to RCU */
#define SLAB_TYPESAFE_BY_RCU ((slab_flags_t __force)0x00080000U)
-/* Spread some memory over cpuset */
-#define SLAB_MEM_SPREAD ((slab_flags_t __force)0x00100000U)
/* Trace allocations and frees */
#define SLAB_TRACE ((slab_flags_t __force)0x00200000U)

@@ -164,6 +162,9 @@
#endif
#define SLAB_TEMPORARY SLAB_RECLAIM_ACCOUNT /* Objects are short-lived */

+/* Obsolete unused flag, to be removed */
+#define SLAB_MEM_SPREAD 0
+
/*
* ZERO_SIZE_PTR will be returned for zero sized kmalloc requests.
*
diff --git a/mm/slab.h b/mm/slab.h
index 54deeb0428c6..f4534eefb35d 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -469,7 +469,6 @@ static inline bool is_kmalloc_cache(struct kmem_cache *s)
SLAB_STORE_USER | \
SLAB_TRACE | \
SLAB_CONSISTENCY_CHECKS | \
- SLAB_MEM_SPREAD | \
SLAB_NOLEAKTRACE | \
SLAB_RECLAIM_ACCOUNT | \
SLAB_TEMPORARY | \

--
2.43.1

[Song, Xiongwei]

> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
> removed. SLUB instead relies on the page allocator's NUMA policies.
> Change the flag's value to 0 to free up the value it had, and mark it
> for full removal once all users are gone.
>
> Reported-by: Steven Rostedt <ros...@goodmis.org>
> Closes: https://lore.kernel.org/all/20240131172...@gandalf.local.home/
> Signed-off-by: Vlastimil Babka <vba...@suse.cz>

Ran a rough test with build and bootup, feel free to add

Tested-by: Xiongwei Song <xiongw...@windriver.com>
Reviewed-by: Xiongwei Song <xiongw...@windriver.com>

[Chengming Zhou]

On 2024/2/21 00:58, Vlastimil Babka wrote:
> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
> removed. SLUB instead relies on the page allocator's NUMA policies.
> Change the flag's value to 0 to free up the value it had, and mark it
> for full removal once all users are gone.
>
> Reported-by: Steven Rostedt <ros...@goodmis.org>
> Closes: https://lore.kernel.org/all/20240131172...@gandalf.local.home/
> Signed-off-by: Vlastimil Babka <vba...@suse.cz>

Reviewed-by: Chengming Zhou <chengmi...@linux.dev>

Thanks!

[Roman Gushchin]

On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote:
0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was

> removed. SLUB instead relies on the page allocator's NUMA policies.
> Change the flag's value to 0 to free up the value it had, and mark it
> for full removal once all users are gone.
>
> Reported-by: Steven Rostedt <ros...@goodmis.org>
> Closes: https://lore.kernel.org/all/20240131172...@gandalf.local.home/
> Signed-off-by: Vlastimil Babka <vba...@suse.cz>

Reviewed-by: Roman Gushchin <roman.g...@linux.dev>

Do you plan to follow up with a patch series removing all usages?

Thanks!

[Song, Xiongwei]

Hi Vlastimil,

If you are not available with it, I can do.

Regards,
Xiongwei

[Chengming Zhou]

Actually, I have done it yesterday. Sorry, I just forgot this task. :)

I plan to send out it after this series merged in the slab branch. And
I'm wondering is it better to put all diffs in one huge patch or split
every diff to each patch?

Thanks!

[Song, Xiongwei]

> On 2024/2/22 09:10, Song, Xiongwei wrote:
> > Hi Vlastimil,
> >
> >> On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote:
> >> 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
> >>> removed. SLUB instead relies on the page allocator's NUMA policies.
> >>> Change the flag's value to 0 to free up the value it had, and mark it
> >>> for full removal once all users are gone.
> >>>
> >>> Reported-by: Steven Rostedt <ros...@goodmis.org>
> >>> Closes: https://lore.kernel.org/all/20240131172...@gandalf.local.home/
> >>> Signed-off-by: Vlastimil Babka <vba...@suse.cz>
> >>
> >> Reviewed-by: Roman Gushchin <roman.g...@linux.dev>
> >>
> >> Do you plan to follow up with a patch series removing all usages?
> >
> > If you are not available with it, I can do.
>
> Actually, I have done it yesterday. Sorry, I just forgot this task. :)

Ok, that's fine.

I remember you said you wanted to do it. But it's been for a long time.
I thinks that's why Vlastimil sent the series out.

You could've said what you've done or your any update when you reviewed
this series yesterday, which wouldn't make others confused. So keeping
update would be better.

Thanks.

[Vlastimil Babka]

I'd suggest you do a patch per subsystem (mostly different filesystems) and
send them out to respective maintainers to pick in their trees. I've talked
to David from btrfs and he suggested this way.

You don't need to wait for this series to be merged. The flag is already a
no-op as of 6.8-rc1. Also I'd suggest sending the patches individually. In a
series they wouldn't depend on each other anyway, and you would either have
to Cc maintainers separately per patch of the series, or everyone on
everything, and there would always be somebody who would prefer the other
way that you pick.

> Thanks!

[Chengming Zhou]

On 2024/2/24 00:41, Vlastimil Babka wrote:
> On 2/22/24 03:32, Chengming Zhou wrote:
>> On 2024/2/22 09:10, Song, Xiongwei wrote:
>>> Hi Vlastimil,
>>>
>>>> On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote:
>>>> 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
>>>>> removed. SLUB instead relies on the page allocator's NUMA policies.
>>>>> Change the flag's value to 0 to free up the value it had, and mark it
>>>>> for full removal once all users are gone.
>>>>>
>>>>> Reported-by: Steven Rostedt <ros...@goodmis.org>
>>>>> Closes: https://lore.kernel.org/all/20240131172...@gandalf.local.home/
>>>>> Signed-off-by: Vlastimil Babka <vba...@suse.cz>
>>>>
>>>> Reviewed-by: Roman Gushchin <roman.g...@linux.dev>
>>>>
>>>> Do you plan to follow up with a patch series removing all usages?
>>>
>>> If you are not available with it, I can do.
>>
>> Actually, I have done it yesterday. Sorry, I just forgot this task. :)
>>
>> I plan to send out it after this series merged in the slab branch. And
>> I'm wondering is it better to put all diffs in one huge patch or split
>> every diff to each patch?
>
> I'd suggest you do a patch per subsystem (mostly different filesystems) and
> send them out to respective maintainers to pick in their trees. I've talked
> to David from btrfs and he suggested this way.

Ok, will send out individually.

>
> You don't need to wait for this series to be merged. The flag is already a
> no-op as of 6.8-rc1. Also I'd suggest sending the patches individually. In a
> series they wouldn't depend on each other anyway, and you would either have
> to Cc maintainers separately per patch of the series, or everyone on
> everything, and there would always be somebody who would prefer the other
> way that you pick.

Right, thanks for your instructions!

>
>> Thanks!
>