* RE: Do we still need SLAB_MEM_SPREAD (and possibly others)? [not found] ` <fb8161d9-16c0-da8c-09ee-905e39ae199b@linux.com> @ 2024-02-06 1:46 ` Song, Xiongwei 2024-02-06 3:16 ` Waiman Long 0 siblings, 1 reply; 5+ messages in thread From: Song, Xiongwei @ 2024-02-06 1:46 UTC (permalink / raw) To: Christoph Lameter (Ampere), Waiman Long, Zefan Li Cc: Chengming Zhou, Vlastimil Babka, Yosry Ahmed, Steven Rostedt, LKML, linux-mm@kvack.org, Andrew Morton, Linus Torvalds, Kees Cook, David Rientjes, Hyeonggon Yoo, Chengming Zhou, Zheng Yejian, cgroups@vger.kernel.org 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 ... }; Regards, Xiongwei ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Do we still need SLAB_MEM_SPREAD (and possibly others)? 2024-02-06 1:46 ` Do we still need SLAB_MEM_SPREAD (and possibly others)? Song, Xiongwei @ 2024-02-06 3:16 ` Waiman Long 2024-02-06 3:20 ` Waiman Long 0 siblings, 1 reply; 5+ messages in thread From: Waiman Long @ 2024-02-06 3:16 UTC (permalink / raw) To: Song, Xiongwei, Christoph Lameter (Ampere), Zefan Li Cc: Chengming Zhou, Vlastimil Babka, Yosry Ahmed, Steven Rostedt, LKML, linux-mm@kvack.org, Andrew Morton, Linus Torvalds, Kees Cook, David Rientjes, Hyeonggon Yoo, Chengming Zhou, Zheng Yejian, cgroups@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Do we still need SLAB_MEM_SPREAD (and possibly others)? 2024-02-06 3:16 ` Waiman Long @ 2024-02-06 3:20 ` Waiman Long 2024-02-06 3:25 ` Chengming Zhou 0 siblings, 1 reply; 5+ messages in thread From: Waiman Long @ 2024-02-06 3:20 UTC (permalink / raw) To: Song, Xiongwei, Christoph Lameter (Ampere), Zefan Li Cc: Chengming Zhou, Vlastimil Babka, Yosry Ahmed, Steven Rostedt, LKML, linux-mm@kvack.org, Andrew Morton, Linus Torvalds, Kees Cook, David Rientjes, Hyeonggon Yoo, Chengming Zhou, Zheng Yejian, cgroups@vger.kernel.org On 2/5/24 22:16, Waiman Long wrote: > > 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. BTW, cpuset doesn't use SLAB_MEM_SPREAD directly. Instead it set the task's PFA_SPREAD_SLAB and let other subsystems test it to act appropriately. Other than cpuset, the latest upstream kernel doesn't check or use this flag at all. Cheers, Longman ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Do we still need SLAB_MEM_SPREAD (and possibly others)? 2024-02-06 3:20 ` Waiman Long @ 2024-02-06 3:25 ` Chengming Zhou 2024-02-06 3:34 ` Waiman Long 0 siblings, 1 reply; 5+ messages in thread From: Chengming Zhou @ 2024-02-06 3:25 UTC (permalink / raw) To: Waiman Long, Song, Xiongwei, Christoph Lameter (Ampere) Cc: Vlastimil Babka, Yosry Ahmed, Steven Rostedt, LKML, linux-mm@kvack.org, Andrew Morton, Linus Torvalds, Zefan Li, Kees Cook, David Rientjes, Hyeonggon Yoo, Chengming Zhou, Zheng Yejian, cgroups@vger.kernel.org On 2024/2/6 11:20, Waiman Long wrote: > > On 2/5/24 22:16, Waiman Long wrote: >> >> 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. > > BTW, cpuset doesn't use SLAB_MEM_SPREAD directly. Instead it set the task's PFA_SPREAD_SLAB and let other subsystems test it to act appropriately. Other than cpuset, the latest upstream kernel doesn't check or use this flag at all. > Ok, get it. So cpuset_do_slab_mem_spread() can be removed, but this cpuset file interface and PFA_SPREAD_SLAB will be keeped. Thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Do we still need SLAB_MEM_SPREAD (and possibly others)? 2024-02-06 3:25 ` Chengming Zhou @ 2024-02-06 3:34 ` Waiman Long 0 siblings, 0 replies; 5+ messages in thread From: Waiman Long @ 2024-02-06 3:34 UTC (permalink / raw) To: Chengming Zhou, Song, Xiongwei, Christoph Lameter (Ampere) Cc: Vlastimil Babka, Yosry Ahmed, Steven Rostedt, LKML, linux-mm@kvack.org, Andrew Morton, Linus Torvalds, Zefan Li, Kees Cook, David Rientjes, Hyeonggon Yoo, Chengming Zhou, Zheng Yejian, cgroups@vger.kernel.org On 2/5/24 22:25, Chengming Zhou wrote: > On 2024/2/6 11:20, Waiman Long wrote: >> On 2/5/24 22:16, Waiman Long wrote: >>> 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. >> BTW, cpuset doesn't use SLAB_MEM_SPREAD directly. Instead it set the task's PFA_SPREAD_SLAB and let other subsystems test it to act appropriately. Other than cpuset, the latest upstream kernel doesn't check or use this flag at all. >> > Ok, get it. So cpuset_do_slab_mem_spread() can be removed, but > this cpuset file interface and PFA_SPREAD_SLAB will be keeped. Yes, for now. Cheers, Longman ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-02-06 3:34 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20240131172027.10f64405@gandalf.local.home>
[not found] ` <CAJD7tkYCrFAXLey-WK8k1Nkt4SoUQ00GWNjU43HJgaLqycBm7Q@mail.gmail.com>
[not found] ` <61af19ca-5f9a-40da-a04d-b04ed27b8754@suse.cz>
[not found] ` <698633db-b066-4f75-b201-7b785819277b@linux.dev>
[not found] ` <PH0PR11MB519280092AA66FAE6BB3FACEEC402@PH0PR11MB5192.namprd11.prod.outlook.com>
[not found] ` <fb8161d9-16c0-da8c-09ee-905e39ae199b@linux.com>
2024-02-06 1:46 ` Do we still need SLAB_MEM_SPREAD (and possibly others)? Song, Xiongwei
2024-02-06 3:16 ` Waiman Long
2024-02-06 3:20 ` Waiman Long
2024-02-06 3:25 ` Chengming Zhou
2024-02-06 3:34 ` Waiman Long
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox