From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FFF9C4828D for ; Tue, 6 Feb 2024 03:26:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BF3F6B007E; Mon, 5 Feb 2024 22:26:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 06FB06B0080; Mon, 5 Feb 2024 22:26:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E784A6B0081; Mon, 5 Feb 2024 22:26:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D8FB46B007E for ; Mon, 5 Feb 2024 22:26:28 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 538EB16022C for ; Tue, 6 Feb 2024 03:26:28 +0000 (UTC) X-FDA: 81759941256.24.0BD0090 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) by imf22.hostedemail.com (Postfix) with ESMTP id 7B584C0002 for ; Tue, 6 Feb 2024 03:26:26 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=tNOLalON; spf=pass (imf22.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.170 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707189986; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ClD2Z6Jo52GcH++My4a6PnVyBVRkcPKgaDGiH7iNA/k=; b=mlyKQWcHjqtiaAbGRac5HfjYuhlZswaF0oyBKzxVn4sDImoJYj1qFDH1LBjk1m05gmEvPM WdR99kR6EVgE5YMtFvyJh/2juS/EuO3/F5ncH+oGLPEzFLDqsbiwYb2i9GOGTvkaDE34nv PvrOdLPi6/p2WXJM5fBZAP/ZiaaTn/M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707189986; a=rsa-sha256; cv=none; b=NynZqyOMW0e7EC2agTQ+FVfHur2Gl+ZaOg71p/2J8NVGF1UCxzRE3hBSP/eAZ2/X/zArpL gzINZXbS8TyOK2RrPDzNjV96df6zjzHUGCL0ARvvJJbpAYagCoB3bnfPExQjY6RovkEQee 2ltUqk8z5H00pCIjoQHuAflqCsH9QKc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=tNOLalON; spf=pass (imf22.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.170 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707189984; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ClD2Z6Jo52GcH++My4a6PnVyBVRkcPKgaDGiH7iNA/k=; b=tNOLalON7SIXvMIFxF/K/Mn422ezvF3obOVRSojEkr+3MyY7JBT2TZoivbxMFGfoheZSZR Cjk3ZAZpBimhXqD+8iYSQYcMYlV8DxvXn2ro4ZHCi5H/JKQ9WJ+o7Rkm9/Fio8gfwcKH7V yhPF3WxlasNzIK//syGGSWpPSfbWb1E= Date: Tue, 6 Feb 2024 11:25:53 +0800 MIME-Version: 1.0 Subject: Re: Do we still need SLAB_MEM_SPREAD (and possibly others)? Content-Language: en-US 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 <42.hyeyoo@gmail.com>, Chengming Zhou , Zheng Yejian , "cgroups@vger.kernel.org" References: <20240131172027.10f64405@gandalf.local.home> <61af19ca-5f9a-40da-a04d-b04ed27b8754@suse.cz> <698633db-b066-4f75-b201-7b785819277b@linux.dev> <2efa10b2-6732-4aa5-98ae-34053a5838ee@redhat.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <2efa10b2-6732-4aa5-98ae-34053a5838ee@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 7B584C0002 X-Rspam-User: X-Stat-Signature: oyfcp3r594k6yw3hag9ec1esb836sutq X-Rspamd-Server: rspam03 X-HE-Tag: 1707189986-745877 X-HE-Meta: U2FsdGVkX1/akG+zA7a2IPFQ8qTfh+C7eL+cWdgdAcT77DpSJtxles+yvzAzWJRwbbxIdhCFlJrGEbtJLdLp8LfdJ/4Z3NWOEteeoLwAyVzPG5E9sbVC75nyS3l3qULq/yRz2/nTLtrjJdKUPk7fbMsvK9zxEhHSou0xBsWlUJeTXRCK94BdV4IxoZ4zbhLu+0l3Aq+wFA8sZeIz/VimjO8O365SHswbkzPhoum8a3DyghBtiR/yLxNhd5Lp/PaOyKmDxMJo5BUVIqp/kVqbOE6sMdu3mhtXxKjt+ajFqGy38FMnZEP+//jLNSldwd1BLE1J0gB933/Z2ZTgny64lH+/Sabj+4ucY0k/zChl0HWm0RSufWgUSd9GwMUsxkY6knGSXX86LwsS5xIkYacMGMd0m1pXIBeQbTqHZpoS8B5C9saQ9rJVd/8+9Xb3gJiqGyYuuggwe9G+kbG6UFk/YKXUCJBsWiuUDBZsLEVqgCk4waDK8nYUOYgG+8DRVLrCt9onaJeIwQBKttZz41EINocFwoNFsPdwbYIMy3pOJgNBH3lAOJtD9GpbZHhgrFMjfSt3hSBzFnt8vLqoqzlBGngy9/irV7JAQVenYDTVvE+wkhHbWngmwogQGRJFoHZhoCQ6Qpuz/Y+4fl00xY3zGdlWxS2nijAbwTbjsdGb6PDRZB0Gn+3bFP8AUMhjAAg+ymY+8yC4b3RDe107E1EPKa8knToRaPMqiN7+od0jPNiVd6RywYFh6WoAlTHD9jcrGlhNHGh2pMbyQAgXSmDzXRWacviJ0UJ4E9PaN+pISvcjUMUa3+zi+UrH+/GF6SJcnIShXxK1LpU+zurWVcsFL3069YgSS44OBgSAgsCo/y41GrYsv35o1SPs5YiDiqV/+1vgkUq7+qzHnxX5oSEgnQDw9kujKrrUkVLrXTNEAuevL922c78r8k+J7DKVylTP8WyAOwyZlyuDKb79KZR DaIEblW7 2Z10x11loxdxj6a+DU+kps6iYkH2YaLUu5PUF X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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.