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 CE807C4167B for ; Wed, 6 Dec 2023 16:14:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EFD56B0087; Wed, 6 Dec 2023 11:14:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 69E796B008C; Wed, 6 Dec 2023 11:14:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 567616B0092; Wed, 6 Dec 2023 11:14:50 -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 45C0B6B0087 for ; Wed, 6 Dec 2023 11:14:50 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EDC67160193 for ; Wed, 6 Dec 2023 16:14:49 +0000 (UTC) X-FDA: 81536891898.28.7F530F4 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf12.hostedemail.com (Postfix) with ESMTP id 7D95540012 for ; Wed, 6 Dec 2023 16:14:47 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=rVDYHIo4; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wGcezhoF; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701879287; 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=1DkhA2HHkFoqZbckox6DnGjYS+3CIXWrTjgL648Eh+A=; b=g8CevRIKH2lYbSji2GctbEcQzF5w5qxiINp0zpdmqbxkfE0b0UXgZ9IM5Xqm5MeycAANeO Br5eiPaQtWlFMR8qnkG4muAJOyKaiYtY5ibQzKLUopw+Izt2xHjg8AUO3xIG/cz0l4r4tX yFAnKqcnWHa9ifKcAbJcvOp9BqAuxbM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701879287; a=rsa-sha256; cv=none; b=MqUf+w9CHpi/NB6JUoMFuUWTEvY43GHE+HhF4ssU/q2U+KCoG+9Q3duK/3tesTULo7gN3C AawOx+nbrVJxIlpQe5isNJ+jmZSyM6EZmc6bFyx6adheF8QaD9IB6QIzQObdC9sKs5J3Y5 6oLPbhjbAIj3+BY5bQ6DLAblGn1/jko= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=rVDYHIo4; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wGcezhoF; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [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 EFCCD1FD16; Wed, 6 Dec 2023 16:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1701879286; h=from:from:reply-to: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=1DkhA2HHkFoqZbckox6DnGjYS+3CIXWrTjgL648Eh+A=; b=rVDYHIo4hZl3CgAy/qvw7vEZtNRCRdfTESHbRMBQO8VBw0d0rNW63/XBf/Nt+0AcZrcAvP 7HHyoUUwu3H20JUtUchQvUVY2ao79AoQvoa75kb0Jbhj+X8fvkrg+bAKD80BaszybU2aiN aFpGKzpH5mVjokxaZEddOKTMp0FlU4w= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1701879286; h=from:from:reply-to: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=1DkhA2HHkFoqZbckox6DnGjYS+3CIXWrTjgL648Eh+A=; b=wGcezhoFzNi07PvT4U4IYxRR6woz2UoJW+32KxW2B60ApVQRCkCpS9Zgns9dneDTvNVNSi xV3jnu9YFjbjnaDQ== 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 C1E9213408; Wed, 6 Dec 2023 16:14:45 +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 ULPVLvWdcGWHXgAAD6G6ig (envelope-from ); Wed, 06 Dec 2023 16:14:45 +0000 Message-ID: <75a71276-dff8-ad3a-d238-fcfa3ab39413@suse.cz> Date: Wed, 6 Dec 2023 17:14:45 +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: [RFC PATCH v2 2/3] mm/slub: unify all sl[au]b parameters with "slab_$param" Content-Language: en-US To: sxwjean@me.com, 42.hyeyoo@gmail.com, cl@linux.com, linux-mm@kvack.org Cc: penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, roman.gushchin@linux.dev, corbet@lwn.net, keescook@chromium.org, arnd@arndb.de, akpm@linux-foundation.org, gregkh@linuxfoundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Xiongwei Song References: <20231203001501.126339-1-sxwjean@me.com> <20231203001501.126339-3-sxwjean@me.com> From: Vlastimil Babka In-Reply-To: <20231203001501.126339-3-sxwjean@me.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7D95540012 X-Rspam-User: X-Stat-Signature: d6x6j3w8i6buxmoc78nxmx1t1w8sp41t X-Rspamd-Server: rspam03 X-HE-Tag: 1701879287-392533 X-HE-Meta: U2FsdGVkX1//mz3z9t8Zs9uGtWwbg06kEksNUJbqtHAqGurOl/oiI2zOs/NZluM4yfUbWqO6vDcti28vR5gBp0mCZhlKfvgDgYA/ye40kg9/DQD2tbcWVJ6W5mABUVbppqC6zoXQD9uncCRgc9neoL+lglB1AxZWGQj/CxmNb2lfCx634+nuOVYBme4yquiuD0kIzhnmZp+GE+T5+CdGEoXGk+F5QMQFklKyzZAxgJ+B0eRtYFyML0yrSbifJKLMIPKsov4l/Vj9ky7SXXDWTiuZn2/CW1bcmxjkfQwrR9oX5HzurX/ujQfbc0YQIc1zCX4YoViUK5e2p8nofAEmDLCeFyGIYJ6hhBxMBCmWC6xor4HYrpybzpK2vjsfRFbCNhcTETalgPOayCrdHbHrYYenreWJx5hwfj0NhssB7XThgb+IbAdbpPSxymCxnDOHFz2vwF/SgUjJFdYTbc8y7OFCyMiHptM/jddYI6RW2z9F8t0SGauOaPhIXmvtlxYDZ65sLenwPta6koay8rnUle98qF5ml91L2qWBDcCElA9Rnvm3644VDoldOJiEUpePnfuImpijYLXY+UdSj/XgqfOhaABlvvnnV7MUVGTFfHR6SZjmCgD10ADpeTYM82ji63aAYepM5x2JGV9rOOiOmgRfCgVZygs7cYhva2RTw6cmQsiVE3jhdhPrkzx5h9CNaBEZEyYHjfg4FjLqjwUbyj13j+++DR4ID9TPhw/tns4yOI6gSKaUNX6K4yA9kozhqBLFprQBybxrbpGDVSz2cBDhbuyBhIgFi8A7N159qGeumSkR+BMxBhIVuaMpaKEZ7nJBth0BM6AYbOvMK7W+BCI9/lHpwuD+h54qZOzifX9JGq1Lgt8pvaQApoKItybCh/Npq01VCnVh30V2+G6bZIm1v50LnWGoGRw6q0H53WUf02LanTsg3k+A9Q7NI5Y0Jfi1dqcqFSmDMhFjVf0 WOF7Am/u O6sTPBTQlJt6tO9OuIvni0DqPjfHCWtTi2W3R5OWNNZeT1QWr/4i8LbCq8ZE08wv1PFcLi/SVhAy+/1bAKsbYua5BuhU0acfUUDJkIYnGPVogplu/7kHYU3gp9mwvcBT0S7/HUTNiwMs6v7X9zLwia/lIBl6f9KPjlLkKfojoLDxlhziwmfehsPhx/u5FsKpNhL3g+ZU9cFYmCxNb3vPdfYEU3M8h0x+H0oJiqQFNx+h4EEscpS90rAL+kN0st0bzChstWVXWrERvKYNwKOr/k1ZUbIwDwiWHcO7o8oX1dh7XtsdL96HgY8VNpWuXC8scDllC+c2Qq7oxcuhSo0I8LFsybg6LpaEQ3ba6yFlvA41ZqraJsYzrlbSe+Cui3mjLxg0xDFsFuMWeEIzMttde5uQydVWkoduo2Wx6qSQcHQx5VzyvoIEkr3DwKlooeMIILxZZ2F46VVAl+P5IglKDmzJqm6MRq8ATMXPWuPOqUgeHbjlCblzcFD26CSX5tJxb4lAV+Gb9ywDnllg8TcuI6y6PAA== 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 12/3/23 01:15, sxwjean@me.com wrote: > From: Xiongwei Song > > Since the SLAB allocator has been removed, so we need to clean up the "we can clean up", as we don't really "need" > sl[au]b_$params. However, the "slab/SLAB" terms should be keep for > long-term rather than "slub/SLUB". Hence, we should use "slab_$param" I'd phrase it: With only one slab allocator left, it's better to use the generic "slab" term instead of "slub" which is an implementation detail. Hence ... > as the primary prefix, which is pointed out by Vlastimil Babka. For more > information please see [1]. > > This patch is changing the following slab parameters > - slub_max_order > - slub_min_order > - slub_min_objects > - slub_debug > to > - slab_max_order > - slab_min_order > - slab_min_objects > - slab_debug > as the primary slab parameters in > Documentation/admin-guide/kernel-parameters.txt and source, and rename all > setup functions of them too. Meanwhile, "slub_$params" can also be passed Not sure about renaming the code at this point, I would just rename the user-visible parameters and their documentation and any comment that refers to the parameters. Functions and variables can come later as part of wider slub/slab change if we decide to do so? > by command line, which is to keep backward compatibility. Also mark all > "slub_$params" as legacy. > > The function > static int __init setup_slub_debug(char *str); > , which is to setup debug flags inside a slab during kernel init, is > changed to setup_slab_debug_flags(), which is to prevent the name > conflict. Because there is another function > void setup_slab_debug(struct kmem_cache *s, struct slab *slab, > void *addr); > , which is to poison slab space, would have name conflict with the prior > one. Another reason to defer code naming changes. > For parameter "slub_debug", beside replacing it with "slab_debug", there > are several global variables, local variables and functions which are > related with the parameter, let's rename them all. > > Remove the separate descriptions for slub_[no]merge, append legacy tip > for them at the end of descriptions of slab_[no]merge. > > I didn't change the parameters in Documentation/mm/slub.rst because the > file name is still "slub.rst", and slub_$params still can be used in > kernel command line to keep backward compatibility. > > [1] https://lore.kernel.org/linux-mm/7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz/ > > Signed-off-by: Xiongwei Song > --- > .../admin-guide/kernel-parameters.txt | 44 +++--- > drivers/misc/lkdtm/heap.c | 2 +- > mm/Kconfig.debug | 6 +- > mm/slab.h | 16 +- > mm/slab_common.c | 8 +- > mm/slub.c | 142 +++++++++--------- > 6 files changed, 109 insertions(+), 109 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 9f94baeb2f82..d01c12e2a247 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5869,6 +5869,8 @@ > slab_merge [MM] > Enable merging of slabs with similar size when the > kernel is built without CONFIG_SLAB_MERGE_DEFAULT. > + (slub_merge is accepted too, but it's supported for > + legacy) How about a shorter note (and always start on new line) (slub_merge legacy name also accepted for now) > > slab_nomerge [MM] > Disable merging of slabs with similar size. May be > @@ -5882,47 +5884,41 @@ > unchanged). Debug options disable merging on their > own. > For more information see Documentation/mm/slub.rst. > + (slub_nomerge is accepted too, but it's supported for > + legacy) > > - 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 > + slab_debug[=options[,slabs][;[options[,slabs]]...] [MM] I think we should re-sort alphabetically after the slub_ -> slab_ change. > + Enabling slab_debug allows one to determine the > culprit if slab objects become corrupted. Enabling > - slub_debug can create guard zones around objects and > + slab_debug can create guard zones around objects and > may poison objects when not in use. Also tracks the > last alloc / free. For more information see > - Documentation/mm/slub.rst. > + Documentation/mm/slub.rst. (slub_debug is accepted > + too, but it's supported for legacy) > > - slub_max_order= [MM, SLUB] > + slab_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. > + Documentation/mm/slub.rst. (slub_max_order is > + accepted too, but it's supported for legacy) > > - slub_min_objects= [MM, SLUB] > + slab_min_objects= [MM] > The minimum number of objects per slab. SLUB will > - increase the slab order up to slub_max_order to > + increase the slab order up to slab_max_order to > generate a sufficiently large slab able to contain > the number of objects indicated. The higher the number > of objects the smaller the overhead of tracking slabs > and the less frequently locks need to be acquired. > For more information see Documentation/mm/slub.rst. > + (slub_min_objects is accepted too, but it's supported > + for legacy) > > - slub_min_order= [MM, SLUB] > + 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. > + lower than slab_max_order. For more information see "lower or equal to" (more precise, while at it) > + Documentation/mm/slub.rst. (slub_min_order is accepted > + too, but it's supported for legacy) > > smart2= [HW] > Format: [,[,...,]] Thanks!