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] [day] [month] [year] [list]
Date:   Wed, 22 Nov 2023 14:59:36 +0900
From:   Hyeonggon Yoo <42.hyeyoo@...il.com>
To:     "Song, Xiongwei" <Xiongwei.Song@...driver.com>
Cc:     "sxwjean@...com" <sxwjean@...com>, "cl@...ux.com" <cl@...ux.com>,
        "penberg@...nel.org" <penberg@...nel.org>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "roman.gushchin@...ux.dev" <roman.gushchin@...ux.dev>,
        "corbet@....net" <corbet@....net>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] mm/slab: remove slab_nomrege and slab_merge

On Wed, Nov 22, 2023 at 2:27 PM Song, Xiongwei
<Xiongwei.Song@...driver.com> wrote:
>
> Hi Hyeonggon,
>
> > -----Original Message-----
> > From: owner-linux-mm@...ck.org <owner-linux-mm@...ck.org> On Behalf Of Hyeonggon
> > Yoo
> > Sent: Tuesday, November 21, 2023 4:44 PM
> > To: sxwjean@...com
> > Cc: cl@...ux.com; penberg@...nel.org; rientjes@...gle.com; iamjoonsoo.kim@....com;
> > vbabka@...e.cz; roman.gushchin@...ux.dev; corbet@....net; linux-mm@...ck.org; linux-
> > doc@...r.kernel.org; linux-kernel@...r.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@...com> wrote:
> > >
> > > From: Xiongwei Song <xiongwei.song@...driver.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ