lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz>
Date:   Fri, 24 Nov 2023 12:24:11 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     sxwjean@...com, 42.hyeyoo@...il.com, linux-mm@...ck.org
Cc:     cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        roman.gushchin@...ux.dev, corbet@....net,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Xiongwei Song <xiongwei.song@...driver.com>
Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove
 slab_max_order and noaliencache

On 11/22/23 15:36, sxwjean@...com wrote:
> From: Xiongwei Song <xiongwei.song@...driver.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@...driver.com>
> ---
> v2: Hyeonggon Yoo <42.hyeyoo@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ