Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
MIME-Version: 1.0
References: <20231203001501.126339-1-sxwjean@me.com> <20231203001501.126339-4-sxwjean@me.com>
 <CAB=+i9TVfzWk=anexu6ARPA21AC-uhjQjf4brZF0XDfVaWraWw@mail.gmail.com> <PH0PR11MB5192C8CFE3FC4CF1BCA74796EC85A@PH0PR11MB5192.namprd11.prod.outlook.com>
In-Reply-To: <PH0PR11MB5192C8CFE3FC4CF1BCA74796EC85A@PH0PR11MB5192.namprd11.prod.outlook.com>
From:   Hyeonggon Yoo <42.hyeyoo@gmail.com>
Date:   Wed, 6 Dec 2023 09:22:32 +0900
Message-ID: <CAB=+i9TM04LaTMNatZH+LBVVy0N30ZzHYE+XqJm72P5wu6bHsA@mail.gmail.com>
Subject: Re: [PATCH v2 3/3] mm/slub: correct the default value of
 slub_min_objects in doc
To:     "Song, Xiongwei" <Xiongwei.Song@windriver.com>
Cc:     "sxwjean@me.com" <sxwjean@me.com>,
        "vbabka@suse.cz" <vbabka@suse.cz>, "cl@linux.com" <cl@linux.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "penberg@kernel.org" <penberg@kernel.org>,
        "rientjes@google.com" <rientjes@google.com>,
        "iamjoonsoo.kim@lge.com" <iamjoonsoo.kim@lge.com>,
        "roman.gushchin@linux.dev" <roman.gushchin@linux.dev>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Dec 5, 2023 at 11:11=E2=80=AFPM Song, Xiongwei
<Xiongwei.Song@windriver.com> wrote:
>
> Hi Hyeonggon,
>
> > -----Original Message-----
> > From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
> > Sent: Tuesday, December 5, 2023 8:54 AM
> > To: sxwjean@me.com
> > Cc: vbabka@suse.cz; cl@linux.com; linux-mm@kvack.org; penberg@kernel.or=
g;
> > rientjes@google.com; iamjoonsoo.kim@lge.com; roman.gushchin@linux.dev;
> > corbet@lwn.net; keescook@chromium.org; arnd@arndb.de; akpm@linux-founda=
tion.org;
> > gregkh@linuxfoundation.org; linux-doc@vger.kernel.org; linux-kernel@vge=
r.kernel.org; Song,
> > Xiongwei <Xiongwei.Song@windriver.com>
> > Subject: Re: [PATCH v2 3/3] mm/slub: correct the default value of slub_=
min_objects in doc
> >
> > On Sun, Dec 3, 2023 at 9:16=E2=80=AFAM <sxwjean@me.com> wrote:
> > >
> > > From: Xiongwei Song <xiongwei.song@windriver.com>
> > >
> > > There is no a value assigned to slub_min_objects by default, it alway=
s
> > > is 0 that is initialized by compiler if no assigned value by command =
line.
> > > min_objects is calculated based on processor numbers in calculate_ord=
er().
> > > For more details, see commit 9b2cd506e5f2 ("slub: Calculate min_objec=
ts
> > > based on number of processors.")
> > >
> > > Signed-off-by: Xiongwei Song <xiongwei.song@windriver.com>
> >
> > While slub_min_objects equals zero by default, 'min_objects' overrides =
it to
> > 4 * (fls(nr_cpus) + 1) when not set. so when slub_min_objects is not
> > set, it would be
> > equal to or higher than 4. I'm not sure this level of implementation
> > detail is worth documenting.
>
> commit 9b2cd506e5f2 ("slub: Calculate min_objects based on number of proc=
essors.")
> has already given "processors min_objects" pair, do we really need to doc=
ument
> the specific detail?

No, I don't think it needs to be documented, but neither do I think
"slub_min_objects is
0 by default" is correctly documented...

> > Also, I think patch 2 should update Documentation/mm/slub.rst too.
> > (slub_$param -> slab_param)
> I think people can know slub_$params are still supported by
> Documentation/mm/slub.rst, so we don't need to say the info again in
> this file.  Is it better to do so just before removing slub_$params
> completely?

If we're deprecating and planning to drop slub_$params in the future,
IMHO it'd be less confusing if we change it now, rather than
when removing slub_$params completely (probably 10 years later)?

Thanks,
Hyeonggon

> > > ---
> > >  Documentation/mm/slub.rst | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst
> > > index be75971532f5..1f4399581449 100644
> > > --- a/Documentation/mm/slub.rst
> > > +++ b/Documentation/mm/slub.rst
> > > @@ -150,7 +150,7 @@ list_lock once in a while to deal with partial sl=
abs. That overhead is
> > >  governed by the order of the allocation for each slab. The allocatio=
ns
> > >  can be influenced by kernel parameters:
> > >
> > > -.. slub_min_objects=3Dx          (default 4)
> > > +.. slub_min_objects=3Dx          (default 0)
> > >  .. slub_min_order=3Dx            (default 0)
> > >  .. slub_max_order=3Dx            (default 3 (PAGE_ALLOC_COSTLY_ORDER=
))
> > >
> > > --
> > > 2.34.1
> > >