From: Xiongwei Song <[email protected]>
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 <[email protected]>
---
v2: Hyeonggon Yoo <[email protected]> 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/[email protected]/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.
-
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.
-
slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
Enabling slub_debug allows one to determine the
culprit if slab objects become corrupted. Enabling
--
2.34.1
On Wed, Nov 22, 2023 at 11:36 PM <[email protected]> wrote:
>
> From: Xiongwei Song <[email protected]>
>
> 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 <[email protected]>
> ---
> v2: Hyeonggon Yoo <[email protected]> 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/[email protected]/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.
> -
> 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.
> -
> slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
> Enabling slub_debug allows one to determine the
> culprit if slab objects become corrupted. Enabling
Acked-by: Hyeonggon Yoo <[email protected]>
Thanks!
--
Hyeonggon
On 11/22/23 15:36, [email protected] wrote:
> From: Xiongwei Song <[email protected]>
>
> 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 <[email protected]>
> ---
> v2: Hyeonggon Yoo <[email protected]> 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/[email protected]/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
Hi Vlastimil,
> -----Original Message-----
> From: Vlastimil Babka <[email protected]>
> Sent: Friday, November 24, 2023 7:24 PM
> To: [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; linux-
> [email protected]; [email protected]; Song, Xiongwei
> <[email protected]>
> Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and
> noaliencache
>
>
> On 11/22/23 15:36, [email protected] wrote:
> > From: Xiongwei Song <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > v2: Hyeonggon Yoo <[email protected]> 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-
> [email protected]/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?
Sorry, I didn't know the SLUB history, thanks for the comments and proposal.
Did you mean the rough diff below?
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 65731b060e3f..db6d2ebe7c7d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5871,10 +5871,12 @@
slram= [HW,MTD]
slab_merge [MM]
+ slub_merge [MM]
Enable merging of slabs with similar size when the
kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
slab_nomerge [MM]
+ slub_nomerge [MM]
Disable merging of slabs with similar size. May be
necessary if there is some reason to distinguish
allocs to different slabs, especially in hardened
@@ -5887,12 +5889,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.
-
slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
Enabling slub_debug allows one to determine the
culprit if slab objects become corrupted. Enabling
@@ -5901,13 +5897,15 @@
last alloc / free. For more information see
Documentation/mm/slub.rst.
- slub_max_order= [MM, SLUB]
+ slab_max_order= [MM]
+ slub_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.
- slub_min_objects= [MM, SLUB]
+ slab_min_objects= [MM]
+ slub_min_objects= [MM]
The minimum number of objects per slab. SLUB will
increase the slab order up to slub_max_order to
generate a sufficiently large slab able to contain
@@ -5916,18 +5914,12 @@
and the less frequently locks need to be acquired.
For more information see Documentation/mm/slub.rst.
- slub_min_order= [MM, SLUB]
+ slub_min_order= [MM]
+ 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.
-
smart2= [HW]
Format: <io1>[,<io2>[,...,<io8>]]
If so I think we should use slab_¶m in mm/slub.c. When hitting "slub_$param"
we need to assign the value to "slab_¶m" like "slab_nomerge", right?
Regards,
Xiongwei
On Fri, Nov 24, 2023 at 8:24 PM Vlastimil Babka <[email protected]> wrote:
>
> On 11/22/23 15:36, [email protected] wrote:
> > From: Xiongwei Song <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > v2: Hyeonggon Yoo <[email protected]> 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/[email protected]/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.
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_nocmpxchg
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[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
> > Enabling slub_debug allows one to determine the
> > culprit if slab objects become corrupted. Enabling
>
On 11/27/23 01:26, Hyeonggon Yoo wrote:
> On Fri, Nov 24, 2023 at 8:24 PM Vlastimil Babka <[email protected]> wrote:
>> > -
>> > 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.
>
> 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_nocmpxchg
> as it's an implementation-specific feature.
Hm but we're going to have only one implementation and I hope that won't
change again (the implementation could furter evolve, even with large
changes, but not split into separate selection again). So I'd rather use
slab_$thing even for parameters that look like implementation specific.
>> 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)
Well we can certainly try deprecate them in few years, just to avoid cruft.
But it's not critical in case that's rejected for some reason.
> and 2) only using slub_$param for slub-specific params would be enough?
>
>> > -
>> > slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
>> > Enabling slub_debug allows one to determine the
>> > culprit if slab objects become corrupted. Enabling
>>
On 11/26/23 08:25, Song, Xiongwei wrote:
> Hi Vlastimil,
>
>> -----Original Message-----
>> From: Vlastimil Babka <[email protected]>
>> Sent: Friday, November 24, 2023 7:24 PM
>> To: [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]; linux-
>> [email protected]; [email protected]; Song, Xiongwei
>> <[email protected]>
>> Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and
>> noaliencache
>>
>>
>> On 11/22/23 15:36, [email protected] wrote:
>> > From: Xiongwei Song <[email protected]>
>> >
>> > 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 <[email protected]>
>> > ---
>> > v2: Hyeonggon Yoo <[email protected]> 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-
>> [email protected]/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?
>
> Sorry, I didn't know the SLUB history, thanks for the comments and proposal.
>
> Did you mean the rough diff below?
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 65731b060e3f..db6d2ebe7c7d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5871,10 +5871,12 @@
> slram= [HW,MTD]
>
> slab_merge [MM]
> + slub_merge [MM]
> Enable merging of slabs with similar size when the
> kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
I'd hope the result look more like this, so the duplicate names are not
so prominent.
slab_merge [MM]
Enable merging of slabs with similar size when the
kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
(slub_merge also accepted as an alias)
Note that it's not just a Documentation change anymore, as many of the
parameters don't have the slab_ variants yet wired up.
>
> slab_nomerge [MM]
> + slub_nomerge [MM]
> Disable merging of slabs with similar size. May be
> necessary if there is some reason to distinguish
> allocs to different slabs, especially in hardened
> @@ -5887,12 +5889,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.
> -
> slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
> Enabling slub_debug allows one to determine the
> culprit if slab objects become corrupted. Enabling
> @@ -5901,13 +5897,15 @@
> last alloc / free. For more information see
> Documentation/mm/slub.rst.
>
> - slub_max_order= [MM, SLUB]
> + slab_max_order= [MM]
> + slub_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.
>
> - slub_min_objects= [MM, SLUB]
> + slab_min_objects= [MM]
> + slub_min_objects= [MM]
> The minimum number of objects per slab. SLUB will
> increase the slab order up to slub_max_order to
> generate a sufficiently large slab able to contain
> @@ -5916,18 +5914,12 @@
> and the less frequently locks need to be acquired.
> For more information see Documentation/mm/slub.rst.
>
> - slub_min_order= [MM, SLUB]
> + slub_min_order= [MM]
> + 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.
> -
> smart2= [HW]
> Format: <io1>[,<io2>[,...,<io8>]]
>
> If so I think we should use slab_¶m in mm/slub.c. When hitting "slub_$param"
> we need to assign the value to "slab_¶m" like "slab_nomerge", right?
>
> Regards,
> Xiongwei
> -----Original Message-----
> From: Vlastimil Babka <[email protected]>
> Sent: Monday, November 27, 2023 8:03 PM
> To: Song, Xiongwei <[email protected]>; [email protected];
> [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; linux-
> [email protected]; [email protected]
> Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and
> noaliencache
>
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content
> is safe.
>
> On 11/26/23 08:25, Song, Xiongwei wrote:
> > Hi Vlastimil,
> >
> >> -----Original Message-----
> >> From: Vlastimil Babka <[email protected]>
> >> Sent: Friday, November 24, 2023 7:24 PM
> >> To: [email protected]; [email protected]; [email protected]
> >> Cc: [email protected]; [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected]; linux-
> >> [email protected]; [email protected]; Song, Xiongwei
> >> <[email protected]>
> >> Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and
> >> noaliencache
> >>
> >>
> >> On 11/22/23 15:36, [email protected] wrote:
> >> > From: Xiongwei Song <[email protected]>
> >> >
> >> > 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 <[email protected]>
> >> > ---
> >> > v2: Hyeonggon Yoo <[email protected]> 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-
> >> [email protected]/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?
> >
> > Sorry, I didn't know the SLUB history, thanks for the comments and proposal.
> >
> > Did you mean the rough diff below?
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-
> guide/kernel-parameters.txt
> > index 65731b060e3f..db6d2ebe7c7d 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -5871,10 +5871,12 @@
> > slram= [HW,MTD]
> >
> > slab_merge [MM]
> > + slub_merge [MM]
> > Enable merging of slabs with similar size when the
> > kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
>
> I'd hope the result look more like this, so the duplicate names are not
> so prominent.
>
> slab_merge [MM]
> Enable merging of slabs with similar size when the
> kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
> (slub_merge also accepted as an alias)
>
> Note that it's not just a Documentation change anymore, as many of the
> parameters don't have the slab_ variants yet wired up.
Ok, thanks. Will create a patch for it.
Regards,
Xiongwei
>
> >
> > slab_nomerge [MM]
> > + slub_nomerge [MM]
> > Disable merging of slabs with similar size. May be
> > necessary if there is some reason to distinguish
> > allocs to different slabs, especially in hardened
> > @@ -5887,12 +5889,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.
> > -
> > slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
> > Enabling slub_debug allows one to determine the
> > culprit if slab objects become corrupted. Enabling
> > @@ -5901,13 +5897,15 @@
> > last alloc / free. For more information see
> > Documentation/mm/slub.rst.
> >
> > - slub_max_order= [MM, SLUB]
> > + slab_max_order= [MM]
> > + slub_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.
> >
> > - slub_min_objects= [MM, SLUB]
> > + slab_min_objects= [MM]
> > + slub_min_objects= [MM]
> > The minimum number of objects per slab. SLUB will
> > increase the slab order up to slub_max_order to
> > generate a sufficiently large slab able to contain
> > @@ -5916,18 +5914,12 @@
> > and the less frequently locks need to be acquired.
> > For more information see Documentation/mm/slub.rst.
> >
> > - slub_min_order= [MM, SLUB]
> > + slub_min_order= [MM]
> > + 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.
> > -
> > smart2= [HW]
> > Format: <io1>[,<io2>[,...,<io8>]]
> >
> > If so I think we should use slab_¶m in mm/slub.c. When hitting "slub_$param"
> > we need to assign the value to "slab_¶m" like "slab_nomerge", right?
> >
> > Regards,
> > Xiongwei