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 9F93FC47DDF for ; Thu, 1 Feb 2024 06:27:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBFDA6B0075; Thu, 1 Feb 2024 01:27:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D48F66B007B; Thu, 1 Feb 2024 01:27:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C10BC6B007E; Thu, 1 Feb 2024 01:27:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AE8FF6B0075 for ; Thu, 1 Feb 2024 01:27:41 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 74BDC40864 for ; Thu, 1 Feb 2024 06:27:41 +0000 (UTC) X-FDA: 81742253922.11.A47AA54 Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) by imf19.hostedemail.com (Postfix) with ESMTP id 6585E1A0012 for ; Thu, 1 Feb 2024 06:27:39 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=axgxy3x6; spf=pass (imf19.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.182 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706768859; a=rsa-sha256; cv=none; b=E9VyDhAc2cJEhGaANp1A2KaX0KohQmWPbrglc/yRZ6U6vSjkrNv+snkTXOq6ZhltQAYrMK 2JNliRIhgRFLoTMlvneiqM9adQyj1bKL7/0kUx+QQHDnPzwhAiu+44mHIWnqKmUXSgfj6Q R+Uaz8bc/dfJUTm73yKcfLs+uERSLQA= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=axgxy3x6; spf=pass (imf19.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.182 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=1706768859; 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=7Qvm1uhfLMC1fJLgXMV0RsQ6nifi9sUu1XYYWSZg8Cw=; b=yrr6uMIrwooWO4vUAOue5CC0Q5d+wo5LM+8biokf5VYFDC54lIiU8aqXkJIQKbNLt/LAmn uoHvbNpyTNj6cJnqHe3k7MyGI3FcjDB9ggvK/LAEKSuFDEO9ysvFiw+kU3nJ7oH+lCuAZC JDza15r2VG/W4uY+Dc/lZH0e9EF3rg0= Message-ID: <698633db-b066-4f75-b201-7b785819277b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1706768857; 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=7Qvm1uhfLMC1fJLgXMV0RsQ6nifi9sUu1XYYWSZg8Cw=; b=axgxy3x6LGdKdzkvApMtvByga7105wOUF1dtMY7024mq4NgCwACDwjDhUz5JSXqBpcikI8 QxyL0TbWBStcU3svB/8WHZMBkM5zFMc3zx4wmhqf3tCS29VKmyNxvhzCmlbx+EEwP/XnU3 g6gIkJKZ09uYjL4q+0W8oyiKXAz+Kw0= Date: Thu, 1 Feb 2024 14:27:23 +0800 MIME-Version: 1.0 Subject: Re: Do we still need SLAB_MEM_SPREAD (and possibly others)? Content-Language: en-US To: Vlastimil Babka , Yosry Ahmed , Steven Rostedt Cc: LKML , linux-mm@kvack.org, Andrew Morton , Linus Torvalds , Kees Cook , Christoph Lameter , David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Xiongwei Song , Chengming Zhou , Zheng Yejian References: <20240131172027.10f64405@gandalf.local.home> <61af19ca-5f9a-40da-a04d-b04ed27b8754@suse.cz> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <61af19ca-5f9a-40da-a04d-b04ed27b8754@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 6585E1A0012 X-Stat-Signature: c4nf319torjb564j6p859zws861r9nkz X-Rspam-User: X-HE-Tag: 1706768859-51706 X-HE-Meta: U2FsdGVkX1/b0dE9TXKdlPy/qEWV9JLbJ1OS+5waFwSqgz8rxAb1eYHvbDxOGjiAYuf+EIv9iCSumOuk1Pks5TG9UPJd1tPys78zvzaJ1VBQgtgCyp0YtBzJcTtPDDlxf6i6GaRo9uA36IWbbTKASVqUSb41/F/icK5cZ3H/TwULNNPvTD77Pr1LC3/c8k6A1ESUuvrlDOvSlhwhMPruo19sfpf6zX9YgstR175J100HPUjK8MriXERkBqDHzLiHvQK4AVTTwyqQ3tm0TAGBC5JwPLGkbz0gDgncM6+BC+1t2kt83OxbAORK98cjibMHfIRHx28kQS75Jwtyk+N83vMNqVM0kbVFeuaPMll87VVbme7aSk+MVFC0KYxacezNvPQ8Q+VGZ9AKU6QufghqaSHMgB2a8UEznIn6R0aCydXeBbo1W74Y6EZh8sNInrWGtsZOCpVEzTFpHGlaQeDTKbyJsZBht4G4ONDYMM6u+odZWmffq3zYuywa6aRiRBk2Wjcbcia9cwoCn5aNHB6KhWiTvptooSbIqT5l/F1Kej95a3xQyaI+SwOLuSVRdILISLDhXbl18cAXnTfBFpGcSpJ3wAt4kfl1SNKNTJJOGI5KM0pP8FHFgpX/BqI1MS+RdQ3YYmzT3q52dV6T3NiwMctkI9bLNvUBDpdTNc65tJHAYel+PO6Sn/Qx4JW4ZbtUGpiFFT2QUbzo9L654zmjbBYAVF+sPwoehZr2DxnQOcNsa+cSqVq3EltLqs0NWagCx+M2s+On+u3YAJjsoj/Els5130NxdFQOb7xnFZBKLbR3C5eDLK0oiWlRXPe6IX/w2suzHI9V096ZOAh7adc4tY+bF0Z7ifKgQ9fv8GEbgBLQzIPuB9jmdOgenfNnkMLzyUf8tnLim1urgb5rapPr+ItBoipKVgyJCE6rFrbRIU9Hg+hIcY95Qtj/PRqCpSkKisUMoiSi9IwB/SQHPXE eonhrppc VqMYslCpfO8uWxHyZEp/zQld9G3nSnFLtnPHlf21j58a0T5RYpQiprKrskOmDHnTRwsYlbHltXS6s7HuP0GtirdQmZZeADwMMkUaodInLUjX3LiWXU3vVGmSBFOc1V8AXgQlof5VzMTzf12sl/mNhufu+4+OeRdCi5Qkw2/rXNB6Wzi1oJmOHH2s9jiNR7J2mjWhg1T7xCJwvsoqLbvshufuL+j5ot+hqB1L5E3PblTYNRcfSpmH+ecpswx7zRFzdqshNrlYDAn7vWs6PrvfUGDikbVhwgvKju7v5aNhbsjW8edi+vwVPG8vStXz++RXBiONPK47wOu5LLCwu2cOdadl/zrObLHTPKOGorPCuNR6PzjaIU49M7dwxEQ== 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/1 06:40, Vlastimil Babka wrote: > On 1/31/24 23:25, Yosry Ahmed wrote: >> On Wed, Jan 31, 2024 at 2:20 PM Steven Rostedt wrote: >>> >>> I was looking into moving eventfs_inode into a slab, and after cutting and >>> pasting the tracefs allocator: >>> >>> tracefs_inode_cachep = kmem_cache_create("tracefs_inode_cache", >>> sizeof(struct tracefs_inode), >>> 0, (SLAB_RECLAIM_ACCOUNT| >>> SLAB_MEM_SPREAD| >>> SLAB_ACCOUNT), >>> init_once); >>> >>> I figured I should know what those slab flags mean. I also looked at what >>> others in fs use for their slabs. The above is rather common (which I >>> probably just copied from another file system), but I wanted to know what >>> they are for. >>> >>> When I got to SLAB_MEM_SPREAD, I found that it's a common flag and there's >>> a lot of caches that just set that and nothing else. >>> >>> But I couldn't find how it was used. >>> >>> Then I found this commit: >>> >>> 16a1d968358a ("mm/slab: remove mm/slab.c and slab_def.h") >>> >>> Which I think removed the only use case of SLAB_MEM_SPREAD. >>> >>> $ git grep SLAB_MEM_SPREAD mm >>> mm/slab.h: SLAB_MEM_SPREAD | \ >>> >>> That's all I find in the mm directory. >>> >>> Is it obsolete now? Can we delete it? Maybe there's other SLAB_* flags that >>> are no longer used. I don't know, I haven't audited them. >> >> Perhaps cpuset_do_slab_mem_spread() as well. > > Yep, good find. Show how obscure mm/slab.c was in the end :) > > CCing a few more new people who did slab changes recently, who'd like some > low hanging fruit of negative diffcount? :) Thanks for CCing, I can prepare the patch to do it. IIUC, what I need to do is: 1. delete SLAB_MEM_SPREAD and all its uses. 2. cpuset_do_slab_mem_spread() is not used anymore, should we keep the interface? Since it's the interface exported by cgroup-v1 "cpuset.memory_spread_slab".