Received-SPF: pass (google.com: domain of linux-kernel+bounces-54246-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <2efa10b2-6732-4aa5-98ae-34053a5838ee@redhat.com>
Date: Mon, 5 Feb 2024 22:20:57 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Do we still need SLAB_MEM_SPREAD (and possibly others)?
Content-Language: en-US
From: Waiman Long <longman@redhat.com>
To: "Song, Xiongwei" <Xiongwei.Song@windriver.com>,
 "Christoph Lameter (Ampere)" <cl@linux.com>,
 Zefan Li <lizefan.x@bytedance.com>
Cc: Chengming Zhou <chengming.zhou@linux.dev>,
 Vlastimil Babka <vbabka@suse.cz>, Yosry Ahmed <yosryahmed@google.com>,
 Steven Rostedt <rostedt@goodmis.org>, LKML <linux-kernel@vger.kernel.org>,
 "linux-mm@kvack.org" <linux-mm@kvack.org>,
 Andrew Morton <akpm@linux-foundation.org>,
 Linus Torvalds <torvalds@linux-foundation.org>,
 Kees Cook <keescook@chromium.org>, David Rientjes <rientjes@google.com>,
 Hyeonggon Yoo <42.hyeyoo@gmail.com>,
 Chengming Zhou <zhouchengming@bytedance.com>,
 Zheng Yejian <zhengyejian1@huawei.com>,
 "cgroups@vger.kernel.org" <cgroups@vger.kernel.org>
References: <20240131172027.10f64405@gandalf.local.home>
 <CAJD7tkYCrFAXLey-WK8k1Nkt4SoUQ00GWNjU43HJgaLqycBm7Q@mail.gmail.com>
 <61af19ca-5f9a-40da-a04d-b04ed27b8754@suse.cz>
 <698633db-b066-4f75-b201-7b785819277b@linux.dev>
 <PH0PR11MB519280092AA66FAE6BB3FACEEC402@PH0PR11MB5192.namprd11.prod.outlook.com>
 <fb8161d9-16c0-da8c-09ee-905e39ae199b@linux.com>
 <PH0PR11MB5192FC6A7AA3CB84BA3BC7E6EC462@PH0PR11MB5192.namprd11.prod.outlook.com>
 <da2417c0-49f1-4674-95f9-297d6cd9e0fa@redhat.com>
In-Reply-To: <da2417c0-49f1-4674-95f9-297d6cd9e0fa@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


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