* [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache @ 2023-11-22 14:36 sxwjean 2023-11-23 0:33 ` Hyeonggon Yoo 2023-11-24 11:24 ` Vlastimil Babka 0 siblings, 2 replies; 8+ messages in thread From: sxwjean @ 2023-11-22 14:36 UTC (permalink / raw) To: 42.hyeyoo, vbabka, linux-mm Cc: cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel, Xiongwei Song 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. - 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache 2023-11-22 14:36 [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache sxwjean @ 2023-11-23 0:33 ` Hyeonggon Yoo 2023-11-24 11:24 ` Vlastimil Babka 1 sibling, 0 replies; 8+ messages in thread From: Hyeonggon Yoo @ 2023-11-23 0:33 UTC (permalink / raw) To: sxwjean Cc: vbabka, linux-mm, cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel, Xiongwei Song On Wed, Nov 22, 2023 at 11:36 PM <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. > - > 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 <42.hyeyoo@gmail.com> Thanks! -- Hyeonggon ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache 2023-11-22 14:36 [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache sxwjean 2023-11-23 0:33 ` Hyeonggon Yoo @ 2023-11-24 11:24 ` Vlastimil Babka 2023-11-26 7:25 ` Song, Xiongwei 2023-11-27 0:26 ` Hyeonggon Yoo 1 sibling, 2 replies; 8+ messages in thread From: Vlastimil Babka @ 2023-11-24 11:24 UTC (permalink / raw) To: sxwjean, 42.hyeyoo, linux-mm Cc: cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel, Xiongwei Song 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache 2023-11-24 11:24 ` Vlastimil Babka @ 2023-11-26 7:25 ` Song, Xiongwei 2023-11-27 12:02 ` Vlastimil Babka 2023-11-27 0:26 ` Hyeonggon Yoo 1 sibling, 1 reply; 8+ messages in thread From: Song, Xiongwei @ 2023-11-26 7:25 UTC (permalink / raw) To: Vlastimil Babka, sxwjean, 42.hyeyoo, linux-mm Cc: cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel Hi Vlastimil, > -----Original Message----- > From: Vlastimil Babka <vbabka@suse.cz> > Sent: Friday, November 24, 2023 7:24 PM > 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; Song, Xiongwei > <Xiongwei.Song@windriver.com> > Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and > noaliencache > > > 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? 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache 2023-11-26 7:25 ` Song, Xiongwei @ 2023-11-27 12:02 ` Vlastimil Babka 2023-11-28 5:18 ` Song, Xiongwei 0 siblings, 1 reply; 8+ messages in thread From: Vlastimil Babka @ 2023-11-27 12:02 UTC (permalink / raw) To: Song, Xiongwei, sxwjean, 42.hyeyoo, linux-mm Cc: cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel On 11/26/23 08:25, Song, Xiongwei wrote: > Hi Vlastimil, > >> -----Original Message----- >> From: Vlastimil Babka <vbabka@suse.cz> >> Sent: Friday, November 24, 2023 7:24 PM >> 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; Song, Xiongwei >> <Xiongwei.Song@windriver.com> >> Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and >> noaliencache >> >> >> 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? > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache 2023-11-27 12:02 ` Vlastimil Babka @ 2023-11-28 5:18 ` Song, Xiongwei 0 siblings, 0 replies; 8+ messages in thread From: Song, Xiongwei @ 2023-11-28 5:18 UTC (permalink / raw) To: Vlastimil Babka, sxwjean, 42.hyeyoo, linux-mm Cc: cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel > -----Original Message----- > From: Vlastimil Babka <vbabka@suse.cz> > Sent: Monday, November 27, 2023 8:03 PM > To: Song, Xiongwei <Xiongwei.Song@windriver.com>; 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 > 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 <vbabka@suse.cz> > >> Sent: Friday, November 24, 2023 7:24 PM > >> 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; Song, Xiongwei > >> <Xiongwei.Song@windriver.com> > >> Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and > >> noaliencache > >> > >> > >> 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? > > > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache 2023-11-24 11:24 ` Vlastimil Babka 2023-11-26 7:25 ` Song, Xiongwei @ 2023-11-27 0:26 ` Hyeonggon Yoo 2023-11-27 11:52 ` Vlastimil Babka 1 sibling, 1 reply; 8+ messages in thread From: Hyeonggon Yoo @ 2023-11-27 0:26 UTC (permalink / raw) To: Vlastimil Babka Cc: sxwjean, linux-mm, cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel, Xiongwei Song On Fri, Nov 24, 2023 at 8:24 PM Vlastimil Babka <vbabka@suse.cz> wrote: > > 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. 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache 2023-11-27 0:26 ` Hyeonggon Yoo @ 2023-11-27 11:52 ` Vlastimil Babka 0 siblings, 0 replies; 8+ messages in thread From: Vlastimil Babka @ 2023-11-27 11:52 UTC (permalink / raw) To: Hyeonggon Yoo Cc: sxwjean, linux-mm, cl, penberg, rientjes, iamjoonsoo.kim, akpm, roman.gushchin, corbet, linux-doc, linux-kernel, Xiongwei Song On 11/27/23 01:26, Hyeonggon Yoo wrote: > On Fri, Nov 24, 2023 at 8:24 PM Vlastimil Babka <vbabka@suse.cz> 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 >> ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-11-28 5:19 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-11-22 14:36 [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache sxwjean 2023-11-23 0:33 ` Hyeonggon Yoo 2023-11-24 11:24 ` Vlastimil Babka 2023-11-26 7:25 ` Song, Xiongwei 2023-11-27 12:02 ` Vlastimil Babka 2023-11-28 5:18 ` Song, Xiongwei 2023-11-27 0:26 ` Hyeonggon Yoo 2023-11-27 11:52 ` Vlastimil Babka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox