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 160B2C4167B for ; Mon, 27 Nov 2023 12:02:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 883AC6B02DC; Mon, 27 Nov 2023 07:02:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 833EF6B02DF; Mon, 27 Nov 2023 07:02:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FCE16B02EB; Mon, 27 Nov 2023 07:02:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 61EBA6B02DC for ; Mon, 27 Nov 2023 07:02:39 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3BAAF120203 for ; Mon, 27 Nov 2023 12:02:39 +0000 (UTC) X-FDA: 81503597238.22.24533D2 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf28.hostedemail.com (Postfix) with ESMTP id 20569C006A for ; Mon, 27 Nov 2023 12:02:33 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701086554; 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; bh=yG4NgQGOqPc/YU1kW/wZ0j96N3Uv1Ycpxe/udce3tIs=; b=urAD6fzm9cLD4TQiDHFt8jG4+rXNyfLxEfHuQh06uZj8lj4PHCQzwoxizJRDWJUYrEdHyX mVZg36YFUjnpD70feytpQB6qG6QHZkqNqnlEYaZgK4q48Ww9C5uzHHgE791SqHuggJawE3 rGigCjN4rANyJTNWMf4CjRZwUTSK/vs= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701086554; a=rsa-sha256; cv=none; b=G25HBQESE2n7G46eJrJC1fMvtKCDbbt1XfFW93TmNxemvsr9gv9citMhvzMzvhU0J3sayh ZKBkqeG+S7V3U17Lsp7usaqFr5/TAUu39Yny2lxfC2U3x1ufe7spMcdwOCFj6ZhfxSnAWH bDuUaea6V6eQVY/+/jSkreEUOCqDRPo= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B496F20363; Mon, 27 Nov 2023 12:02:31 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 949D41379A; Mon, 27 Nov 2023 12:02:31 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 6RnMI1eFZGVudgAAD6G6ig (envelope-from ); Mon, 27 Nov 2023 12:02:31 +0000 Message-ID: <2f8e8e28-28d4-b0a4-11a8-639f78c319c3@suse.cz> Date: Mon, 27 Nov 2023 13:02:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache Content-Language: en-US To: "Song, Xiongwei" , "sxwjean@me.com" , "42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>, "linux-mm@kvack.org" Cc: "cl@linux.com" , "penberg@kernel.org" , "rientjes@google.com" , "iamjoonsoo.kim@lge.com" , "akpm@linux-foundation.org" , "roman.gushchin@linux.dev" , "corbet@lwn.net" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20231122143603.85297-1-sxwjean@me.com> <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: ++++++ X-Rspam-User: X-Stat-Signature: qrc4cfa6ayporwyznszwkej5s9dmoyrn X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 20569C006A X-HE-Tag: 1701086553-385289 X-HE-Meta: U2FsdGVkX187BiXm2OUfAY1YXe6V3mvLElcrvQzOZteMxEKs3TKkbYCSA+V4A2AM3XvfTkmpZowkKJrY+L7BxFtZEgjHvUuYZ3cINlPKX2q5RbpZFWMydqFUBDuTxt+HJmXdIwCRRAm0z1LbDARAT583spFaohJML8HW/XzkF38NBHMheeNh/SvHVCBlwiWBcdULs2jLkBFeDsOUQYPBrjxYVar2a4QAO+DEXyjY/A5987utd2+smccXUQp44ojUZsfpTq5xHFNnuVPuyQWsvE/QWgeiQWTzjHi7GseV9eY7sq25/s8iZ5OW8nfyKQgng4qsav74oVM6MSIMUYIQMoU3vHFguPtrZuHJJfe1gdBFbj3s6JjP+PFsA2Q08eKMM/jPZuI1v0I7h9gYX1TC1ZcSfzIOL/x2YrHW8GjglzBbVzytBJSib0KwWPncLteRKNAL8yKJCN5koy8atPtnyDMwtGAks/mn/lG7ZupgMzSIzb19exm4i4cOnK50Ypz5vdRj52yY6cYWUohssOHg8kBQThy2gf+38ffxWM77BQ31FEB3Q6OQU1T+W2sqA6z5GKB2P8I/XKPU+En5PNGUHLmuUK0/3/54dGd4IzrpPm5zYncgZOCsw3SItboS3eIltX27zUjOg/wxXdG/sIcUv/ePhO62CN5YwUud9IyULg8xhYdFXF2/d39l/VWiZ37nRTXpwq+elg4zqL481pA1On4PIhkOezirr9gDB6Wu0H7wr/nUVZkk4zp4X+AVgub2QlBorhLAF/stgTpZymaTUcAfSvxUT1uDzS1XxTNu6VLBplyAi0jbJS6tvUc7bfo7Cjo32k80Ifmt2w/VBJHeWWVTqAPem+7bsmJCPPVG3L0V2Po2OuIHsIq3BmVGcYtJc/H1+/WA1WR9dvM5YSZoUBUFD6+2DuIv+8+m3DAM7VWHbkIke/GUq1DIhGxf1XG3mRXMhsoUSyVA1TRc1Pn XR0tTclR UOmGXdEfrDv/hmJkrJSwlto9j80+xv0ayDpTXk94BDVpZ1viMktZxWm9wKlLdkY64uZ8BX27GggijgPYmpPsRHoqwb0y/FFTiEXvtfcq5mgxcSVKziZ0LkFZE6/xFO2eNY2w5bKH+ERU0dKrE/ZIYS0SbKbeSV/WapLNpBtAKuM+MXyOM8HMBpDcMyk10roUPg7F/10HEK4YTxmvSewh859DJzR+ZdPoYxyikJ+x93r2WzUzTiWj+ItCRbPAAg33zQ1kZoLsD0ce8JtOz4hdAf07pqPF4Osnm1BcUCo0AJKBBNFihoH0uyuJoR7X6//eiS6x/4Fq86oylGKsakqSX5W1sGY7+jA76PQD427Vngt8N/a1FuBRcZR+pTBDr2FT+DdVg3pDQSMPTFsDDnazKdH8ZgC41wWg1IN9tCV1nwL8WJup3slp7RtfCq12CFzrCPYwm+UuL0OXd/FaETMvAKyasw/FZ47qFCKip8EJVJunssBRe2dN5ogcjfAijqdfyHVD30NTyfTEOkYNKM3ZgrS/IPKkER67UP6xxqLR0bxgmQVEfOUvtVHAmzKY16lpe6tkVi3mC3teTT/6h2EHu9awDlPBdz7OTYoSbcNmT3ihKqvMLNlPqo3l9Nuq4oNdFxjJUaWrH7myF77IN7B9ZW8ABQP7BWYGyCivYGSwpLAZeaUeeFEEo3piUQI4egrIcdpBMiwhZyJ8HRU8lGE7Ir8otThuyolvGzAMetYs3TiQrvD+1ut4IdFszZr/OHEZFckxc 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 11/26/23 08:25, Song, Xiongwei wrote: > Hi Vlastimil, > >> -----Original Message----- >> From: Vlastimil Babka >> Sent: Friday, November 24, 2023 7:24 PM >> To: sxwjean@me.com; 42.hyeyoo@gmail.com; linux-mm@kvack.org >> Cc: cl@linux.com; penberg@kernel.org; rientjes@google.com; iamjoonsoo.kim@lge.com; >> akpm@linux-foundation.org; roman.gushchin@linux.dev; corbet@lwn.net; linux- >> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Song, Xiongwei >> >> Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and >> noaliencache >> >> >> On 11/22/23 15:36, sxwjean@me.com wrote: >> > From: Xiongwei Song >> > >> > Since slab allocator has already been removed. There is no users about >> > slab_max_order and noaliencache, so let's remove them. >> > >> > Signed-off-by: Xiongwei Song >> > --- >> > v2: Hyeonggon Yoo <42.hyeyoo@gmail.com> suggested that noaliencache should be >> > removed too. Here adding this change. The patch is based on [1]. >> > >> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-remove- >> slab-v2r1 >> > >> > v1: https://lore.kernel.org/linux-mm/20231120091214.150502-1- >> sxwjean@me.com/T/#m55ebb45851bc86d650baf65dfe8296d33c5b1126 >> > --- >> > Documentation/admin-guide/kernel-parameters.txt | 10 ---------- >> > 1 file changed, 10 deletions(-) >> > >> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin- >> guide/kernel-parameters.txt >> > index 65731b060e3f..d56a5beefe24 100644 >> > --- a/Documentation/admin-guide/kernel-parameters.txt >> > +++ b/Documentation/admin-guide/kernel-parameters.txt >> > @@ -3740,10 +3740,6 @@ >> > no5lvl [X86-64,RISCV] Disable 5-level paging mode. Forces >> > kernel to use 4-level paging instead. >> > >> > - noaliencache [MM, NUMA, SLAB] Disables the allocation of alien >> > - caches in the slab allocator. Saves per-node memory, >> > - but will impact performance. >> >> No question about this one, can be deleted. >> >> > - >> > noalign [KNL,ARM] >> > >> > noaltinstr [S390] Disables alternative instructions patching >> > @@ -5887,12 +5883,6 @@ >> > own. >> > For more information see Documentation/mm/slub.rst. >> > >> > - slab_max_order= [MM, SLAB] >> > - Determines the maximum allowed order for slabs. >> > - A high setting may cause OOMs due to memory >> > - fragmentation. Defaults to 1 for systems with >> > - more than 32MB of RAM, 0 otherwise. >> >> I think here we should consider the long-term plan first. It's a bit >> unfortunate (in hindsight) SLUB brought its own prefix of parameters, even >> if some became interchangeable aliases later (slab/slub_nomerge), some not. >> I think it would be best to unify them, and consider the string "slub" an >> implementation detail of the general "slab allocator" term going forward. >> >> So what I'd propose is that we change all parameters to accept a >> "slab_$param" as a primary and documented name (and the description can >> contain just [MM] tag, no [SLAB] or [SLUB] needed), with "slub_$param" is >> also accepted as an alias where it exists today, and there's just a note >> that the slub_$param name is also accepted in the description of the >> canonical parameter, not in a separate description. Then maybe in a few >> years we can mark the old names as deprecated and start issuing low-key >> warnings (while still accepting them), and in 10 years maybe remove them >> completely. Thoughts? > > Sorry, I didn't know the SLUB history, thanks for the comments and proposal. > > Did you mean the rough diff below? > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 65731b060e3f..db6d2ebe7c7d 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5871,10 +5871,12 @@ > slram= [HW,MTD] > > slab_merge [MM] > + slub_merge [MM] > Enable merging of slabs with similar size when the > kernel is built without CONFIG_SLAB_MERGE_DEFAULT. I'd hope the result look more like this, so the duplicate names are not so prominent. slab_merge [MM] Enable merging of slabs with similar size when the kernel is built without CONFIG_SLAB_MERGE_DEFAULT. (slub_merge also accepted as an alias) Note that it's not just a Documentation change anymore, as many of the parameters don't have the slab_ variants yet wired up. > > slab_nomerge [MM] > + slub_nomerge [MM] > Disable merging of slabs with similar size. May be > necessary if there is some reason to distinguish > allocs to different slabs, especially in hardened > @@ -5887,12 +5889,6 @@ > own. > For more information see Documentation/mm/slub.rst. > > - slab_max_order= [MM, SLAB] > - Determines the maximum allowed order for slabs. > - A high setting may cause OOMs due to memory > - fragmentation. Defaults to 1 for systems with > - more than 32MB of RAM, 0 otherwise. > - > slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB] > Enabling slub_debug allows one to determine the > culprit if slab objects become corrupted. Enabling > @@ -5901,13 +5897,15 @@ > last alloc / free. For more information see > Documentation/mm/slub.rst. > > - slub_max_order= [MM, SLUB] > + slab_max_order= [MM] > + slub_max_order= [MM] > Determines the maximum allowed order for slabs. > A high setting may cause OOMs due to memory > fragmentation. For more information see > Documentation/mm/slub.rst. > > - slub_min_objects= [MM, SLUB] > + slab_min_objects= [MM] > + slub_min_objects= [MM] > The minimum number of objects per slab. SLUB will > increase the slab order up to slub_max_order to > generate a sufficiently large slab able to contain > @@ -5916,18 +5914,12 @@ > and the less frequently locks need to be acquired. > For more information see Documentation/mm/slub.rst. > > - slub_min_order= [MM, SLUB] > + slub_min_order= [MM] > + slab_min_order= [MM] > Determines the minimum page order for slabs. > Must be > lower than slub_max_order. > For more information see Documentation/mm/slub.rst. > > - slub_merge [MM, SLUB] > - Same with slab_merge. > - > - slub_nomerge [MM, SLUB] > - Same with slab_nomerge. This is supported for > legacy. > - See slab_nomerge for more information. > - > smart2= [HW] > Format: [,[,...,]] > > If so I think we should use slab_¶m in mm/slub.c. When hitting "slub_$param" > we need to assign the value to "slab_¶m" like "slab_nomerge", right? > > Regards, > Xiongwei