lkml.org 
[lkml]   [2024]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Do we still need SLAB_MEM_SPREAD (and possibly others)?
From

On 2/5/24 20:46, Song, Xiongwei wrote:
> Adding the maintainers of cpuset of cgroup.
>
>> On Sun, 4 Feb 2024, Song, Xiongwei wrote:
>>
>>> Once SLAB_MEM_SPREAD is removed, IMO, cpuset.memory_spread_slab is useless.
>> SLAB_MEM_SPREAD does not do anything anymore. SLUB relies on the
>> "spreading" via the page allocator memory policies instead of doing its
>> own like SLAB used to do.
>>
>> What does FILE_SPREAD_SLAB do? Dont see anything there either.
> The FILE_SPREAD_SLAB flag is used by cpuset.memory_spread_slab with read/write operations:
>
> In kernel/cgroup/cpuset.c,
> static struct cftype legacy_files[] = {
> ... snip ...
> {
> .name = "memory_spread_slab",
> .read_u64 = cpuset_read_u64,
> .write_u64 = cpuset_write_u64,
> .private = FILE_SPREAD_SLAB,
> },
> ... snip ...
> };

It looks like that memory_spread_slab may have effect only on the slab
allocator. With the removal of the slab allocator, memory_spread_slab is
now a no-op. However, the memory_spread_slab cgroupfs file is an
externally visible API. So we can't just remove it as it may break
existing applications. We can certainly deprecate it and advise users
not to use it.

Cheers,
Longman



\
 
 \ /
  Last update: 2024-05-27 14:50    [W:0.077 / U:1.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site