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 BB8C4C61D97 for ; Fri, 24 Nov 2023 11:24:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B1278D0071; Fri, 24 Nov 2023 06:24:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 361778D006E; Fri, 24 Nov 2023 06:24:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 229CB8D0071; Fri, 24 Nov 2023 06:24:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 155908D006E for ; Fri, 24 Nov 2023 06:24:19 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EAE644102E for ; Fri, 24 Nov 2023 11:24:18 +0000 (UTC) X-FDA: 81492614196.07.D00A19A Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf13.hostedemail.com (Postfix) with ESMTP id AEBA720002 for ; Fri, 24 Nov 2023 11:24:15 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.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=1700825056; 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=4HFnnd7T3Jj4haAAd/yrxGweVzt/WmCq881aBqIrwdQ=; b=2Daxzp7uXYhgNXqccWqdMz6Xi3QR1pCY5omaA0P7Fgx1OkYvnABAmU6XdL8JrP8keNutLA khIgF7gm7w4h9702lwwkzRgEkWrYkVxs8gOzxPPrIrxWaNQJIWHYx1oScVKINsh2T8PqGe 2TGpzWDthgXUygeZnpq0PHqv6tZV8LQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.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=1700825056; a=rsa-sha256; cv=none; b=GqKQ7PZfC0OMzdcU0UIdKDZ9uaHcfIEETCUpdt0BHp4OG5mKCp8NMkyGrZ3SFir3eR2ar8 J1uvlxmvyDhrrglA+pg6TRWWR1ncpP4L0Sf4VSYTl9xs4zOisDqDS0foR7Dpp7sGtXSrrF MJFHj1nP+Tw3EX5vO+VD7zt7c6iqoLI= 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 CA73D1FD49; Fri, 24 Nov 2023 11:24:11 +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 AD77613A98; Fri, 24 Nov 2023 11:24:11 +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 O5n8KduHYGV7DQAAD6G6ig (envelope-from ); Fri, 24 Nov 2023 11:24:11 +0000 Message-ID: <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz> Date: Fri, 24 Nov 2023 12:24:11 +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: 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, Xiongwei Song References: <20231122143603.85297-1-sxwjean@me.com> From: Vlastimil Babka In-Reply-To: <20231122143603.85297-1-sxwjean@me.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: ++++++++++++++++++++ X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: AEBA720002 X-Stat-Signature: zx34t75hjgsc1efwhuunbxmmub8tte98 X-HE-Tag: 1700825055-50026 X-HE-Meta: U2FsdGVkX186fkyAeJm9O0wjUiBKaGZqvhobeVaEE5N/a5yCwv6tK0Xic7XG017l4kmOGz61XIejEriHbvxvozuxPSxzzanOl+HIxexVOFpnUzDD41Z+BtVAC2L+KIU/8HXn+jvXh3wTYws3s/IaUmKvPQVvCmz6+k6APMN3VjKoakJVJvF8CTaaqvYT8Boil/qNhUxgcZHWaULiGe9AKarQ7GGG00Mp+Abh+AQnrbjT/souWNDKtiSyZth1JwVEZ4GTT4bz4jnn/vvRh7JLJl4r6zdhP7R8h7UYixc7tmY80f4cThK5lF4vUsfTSKvuRuVgam/ZLkdO8nTx9LFUE0pUfYxc4IjcbbtZpKhoU5Ur4SHc57Stc+D1zfv+VrWHrHuF6nusLQPuPb9enOksl0HijFRjXOR8G/+h8dVltmO2s/Dl6+tEJZc49UPtDJr3YmtDSdeI/xtujW4qT8E90QfQyTN+u5hxg3RroESiGQj773/4tQTuPh5LLijChKFaIX0FsMBQA/PZgRAjzTQDpO6HWpO88qoMam/8vT//C4gpEMdMbBBHEtNb2/wGtR7NWY4sxxVcUNl5g6wdw0mMQWedLCu5b+neJVzBN5idkkxjO190SMhzyS6HDMsc0MO6z9fd7ukzR395IxQyyb9k9nQjIT30rejDM8KTBuY7PwFmbie9ktgqQ2RBtWT7jeZQJ83VdqyBj/7oLec6wTTgtUbRUf04Xiftds4Q4D6FvzLKCSR5pCE1lWpB6Ipe7fHu0Q9anS4Qlr+1xmcrMgeQgGE5IzhDN9Ov9T4nGCgUwKWrjGDzmsRmi7QXOOflFG/0unAM0DHzxKf2KeOSXH+q2nRn0rCmB785g81qs58vOxf8lBU2kvUB62PYDQUg8+w4Sln2sJYXX22g75hfZPvMY7bmDhdAWDe32gxjpoSRVjCTxQ3rzELtjlAvL/VKRbpAmeqdaZ0pr11aNZ4xtsX tfb/9rx7 JEujnlXwhUQP5LFkX1Hzv4Q22GF1kJOraay8IXlZxAaPL0gD5zrkjq8Bu5tOIs7VbFHC88zT20i3/JRuMPpyoGIx9Szh9OgkENIoW33rwQAMYlcLrmaRkR9wK/eWfgzRc2cc8WShW5TyJVi3ByzVKgAvh9fh3zBM9RycwScPnfRRNRSkYhJSO8PSuI0XiIS41GGX90rT0kCliTDasjtzPNmvf5xODKF06gl+Uq9o0+ErGuHzKhuDzgII5UbujMBMSQkm2CB5n0M0C+EDgH4+YYfQ1tO5u2H0wnfn7UJVKtDS8Kz3B63YpH4RnbQ09MSsWsSg8f/iHfGMl4FKD+iDx/9CLFdHiKZtxMyB3cKzI6kKhUB2oQp+Z+52l5zkJANFJibjuwiz+P+Jf5uWS1eHwNdr5Vw== 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/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? > - > slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB] > Enabling slub_debug allows one to determine the > culprit if slab objects become corrupted. Enabling