| Message ID | 20231120091214.150502-3-sxwjean@me.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | supplement of slab removal | expand |
On Mon, Nov 20, 2023 at 6:12 PM <sxwjean@me.com> wrote: > > From: Xiongwei Song <xiongwei.song@windriver.com> > > Since slab allocatoer has already been removed, so we should also remove > the related parameters. And change the global flag from slab_nomerge > to slub_nomerge. No, kernel parameters should be changed only in a backward-compatible way (if possible) Before slab merging was supported in SLAB, only SLUB supported it. After commit 423c929cbbec ("mm/slab_common: commonize slab merge logic"), using slab_[no]merge parameters for CONFIG_SLUB builds became legal. I think what the documentation says is "slab_[no]merge enables or disables slab merging and slub_[no]merge remain supported only for backward compatibility" > > Signed-off-by: Xiongwei Song <xiongwei.song@windriver.com> > --- > Documentation/admin-guide/kernel-parameters.txt | 11 ++--------- > mm/Kconfig | 2 +- > mm/slab_common.c | 13 +++++-------- > 3 files changed, 8 insertions(+), 18 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index c7709a11f8ce..afca9ff7c9f0 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5870,11 +5870,11 @@ > > 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 > @@ -5915,13 +5915,6 @@ > 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>]]
Hi Hyeonggon, > -----Original Message----- > From: owner-linux-mm@kvack.org <owner-linux-mm@kvack.org> On Behalf Of Hyeonggon > Yoo > Sent: Tuesday, November 21, 2023 4:44 PM > To: sxwjean@me.com > Cc: cl@linux.com; penberg@kernel.org; rientjes@google.com; iamjoonsoo.kim@lge.com; > vbabka@suse.cz; roman.gushchin@linux.dev; corbet@lwn.net; linux-mm@kvack.org; linux- > doc@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 2/4] mm/slab: remove slab_nomrege and slab_merge > > 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 Mon, Nov 20, 2023 at 6:12 PM <sxwjean@me.com> wrote: > > > > From: Xiongwei Song <xiongwei.song@windriver.com> > > > > Since slab allocatoer has already been removed, so we should also remove > > the related parameters. And change the global flag from slab_nomerge > > to slub_nomerge. > > No, kernel parameters should be changed only in a backward-compatible > way (if possible) > > Before slab merging was supported in SLAB, only SLUB supported it. > After commit 423c929cbbec ("mm/slab_common: commonize slab merge logic"), using > slab_[no]merge parameters for CONFIG_SLUB builds became legal. > > I think what the documentation says is "slab_[no]merge enables or > disables slab merging > and slub_[no]merge remain supported only for backward compatibility" Yes. But slab allocator will not exist anymore. Is slab_[no]merge still proper? Will the term "slab/SLAB" still be used in the future? Regards, Xiongwei > > > > > Signed-off-by: Xiongwei Song <xiongwei.song@windriver.com> > > --- > > Documentation/admin-guide/kernel-parameters.txt | 11 ++--------- > > mm/Kconfig | 2 +- > > mm/slab_common.c | 13 +++++-------- > > 3 files changed, 8 insertions(+), 18 deletions(-) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin- > guide/kernel-parameters.txt > > index c7709a11f8ce..afca9ff7c9f0 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -5870,11 +5870,11 @@ > > > > 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 > > @@ -5915,13 +5915,6 @@ > > 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>]]
On Wed, Nov 22, 2023 at 2:27 PM Song, Xiongwei <Xiongwei.Song@windriver.com> wrote: > > Hi Hyeonggon, > > > -----Original Message----- > > From: owner-linux-mm@kvack.org <owner-linux-mm@kvack.org> On Behalf Of Hyeonggon > > Yoo > > Sent: Tuesday, November 21, 2023 4:44 PM > > To: sxwjean@me.com > > Cc: cl@linux.com; penberg@kernel.org; rientjes@google.com; iamjoonsoo.kim@lge.com; > > vbabka@suse.cz; roman.gushchin@linux.dev; corbet@lwn.net; linux-mm@kvack.org; linux- > > doc@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 2/4] mm/slab: remove slab_nomrege and slab_merge > > > > 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 Mon, Nov 20, 2023 at 6:12 PM <sxwjean@me.com> wrote: > > > > > > From: Xiongwei Song <xiongwei.song@windriver.com> > > > > > > Since slab allocatoer has already been removed, so we should also remove > > > the related parameters. And change the global flag from slab_nomerge > > > to slub_nomerge. > > > > No, kernel parameters should be changed only in a backward-compatible > > way (if possible) > > > > Before slab merging was supported in SLAB, only SLUB supported it. > > After commit 423c929cbbec ("mm/slab_common: commonize slab merge logic"), using > > slab_[no]merge parameters for CONFIG_SLUB builds became legal. > > > > I think what the documentation says is "slab_[no]merge enables or > > disables slab merging > > and slub_[no]merge remain supported only for backward compatibility" > > Yes. But slab allocator will not exist anymore. Is slab_[no]merge still proper? > Will the term "slab/SLAB" still be used in the future? Well, why break existing users for no strong reason? The reason why commit 423c929c did not drop slub_[no]merge after commonization is to support existing users and avoid breaking what worked before. Removing slab_max_order made sense because SLAB has gone and it didn't have any effect on SLUB, but slab_[no]merge are not the case. Also, technically SLUB is an implementation of the slab allocator concept, so IMHO it is not an improper name. and (let's say) even if it is improper, I'm not sure if changing everything would be worth it: $ git grep 'slab' mm | wc -l 2365 -- Thanks! Hyeonggon
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index c7709a11f8ce..afca9ff7c9f0 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5870,11 +5870,11 @@ 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 @@ -5915,13 +5915,6 @@ 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>]] diff --git a/mm/Kconfig b/mm/Kconfig index 766aa8f8e553..87c3f2e1d0d3 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -255,7 +255,7 @@ config SLAB_MERGE_DEFAULT cache layout), which makes such heap attacks easier to exploit by attackers. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache. To disable - merging at runtime, "slab_nomerge" can be passed on the kernel + merging at runtime, "slub_nomerge" can be passed on the kernel command line. config SLAB_FREELIST_RANDOM diff --git a/mm/slab_common.c b/mm/slab_common.c index 238293b1dbe1..d707abd31926 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -58,26 +58,23 @@ static DECLARE_WORK(slab_caches_to_rcu_destroy_work, /* * Merge control. If this is set then no merging of slab caches will occur. */ -static bool slab_nomerge = !IS_ENABLED(CONFIG_SLAB_MERGE_DEFAULT); +static bool slub_nomerge = !IS_ENABLED(CONFIG_SLAB_MERGE_DEFAULT); static int __init setup_slab_nomerge(char *str) { - slab_nomerge = true; + slub_nomerge = true; return 1; } static int __init setup_slab_merge(char *str) { - slab_nomerge = false; + slub_nomerge = false; return 1; } __setup_param("slub_nomerge", slub_nomerge, setup_slab_nomerge, 0); __setup_param("slub_merge", slub_merge, setup_slab_merge, 0); -__setup("slab_nomerge", setup_slab_nomerge); -__setup("slab_merge", setup_slab_merge); - /* * Determine the size of a slab object */ @@ -138,7 +135,7 @@ static unsigned int calculate_alignment(slab_flags_t flags, */ int slab_unmergeable(struct kmem_cache *s) { - if (slab_nomerge || (s->flags & SLAB_NEVER_MERGE)) + if (slub_nomerge || (s->flags & SLAB_NEVER_MERGE)) return 1; if (s->ctor) @@ -163,7 +160,7 @@ struct kmem_cache *find_mergeable(unsigned int size, unsigned int align, { struct kmem_cache *s; - if (slab_nomerge) + if (slub_nomerge) return NULL; if (ctor)