Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
MIME-Version: 1.0
References: <20231122143603.85297-1-sxwjean@me.com> <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz>
In-Reply-To: <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz>
From:   Hyeonggon Yoo <42.hyeyoo@gmail.com>
Date:   Mon, 27 Nov 2023 09:26:55 +0900
Message-ID: <CAB=+i9Rw2Cm1SEYJu8oLBBxy-gaTLty64buma+FHs81pkSQz6w@mail.gmail.com>
Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove
 slab_max_order and noaliencache
To:     Vlastimil Babka <vbabka@suse.cz>
Cc:     sxwjean@me.com, linux-mm@kvack.org, 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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Nov 24, 2023 at 8:24=E2=80=AFPM Vlastimil Babka <vbabka@suse.cz> wr=
ote:
>
> 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 sho=
uld 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/lo=
g/?h=3Dslab-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/Document=
ation/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. Force=
s
> >                       kernel to use 4-level paging instead.
> >
> > -     noaliencache    [MM, NUMA, SLAB] Disables the allocation of alien
> > -                     caches in the slab allocator.  Saves per-node mem=
ory,
> > -                     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.rs=
t.
> >
> > -     slab_max_order=3D [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, eve=
n
> if some became interchangeable aliases later (slab/slub_nomerge), some no=
t.

Good point, thank you for pointing them out!

> 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 slab_{nomerge,min_objects,min_order, ...etc} are common to the
concept of slab so slab_$param will be appropriate.

But if we add something like slub_nocmpxchg later, it would be slub_nocmpxc=
hg
as it's an implementation-specific feature.

> 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.

No reason not to do it.

> 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?

That might be the safest way to remove a kernel parameter but should
we remove them?
Probably 1) allowing both slub_$param and slab_$param for general
parameters (forever)
and 2) only using slub_$param for slub-specific params would be enough?

> > -
> >       slub_debug[=3Doptions[,slabs][;[options[,slabs]]...]      [MM, SL=
UB]
> >                       Enabling slub_debug allows one to determine the
> >                       culprit if slab objects become corrupted. Enablin=
g
>