Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
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 <xiongwei.song@windriver.com>
References: <20231122143603.85297-1-sxwjean@me.com>
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <20231122143603.85297-1-sxwjean@me.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/22/23 15:36, sxwjean@me.com wrote:
> From: Xiongwei Song <xiongwei.song@windriver.com>
> 
> 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 <xiongwei.song@windriver.com>
> ---
> 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