Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Message-ID: <3cb4c839-caa4-5c6e-1672-6498124d3930@suse.cz>
Date:   Mon, 27 Nov 2023 12:52:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove
 slab_max_order and noaliencache
Content-Language: en-US
To:     Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc:     sxwjean@me.com, linux-mm@kvack.org, 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,
        Xiongwei Song <xiongwei.song@windriver.com>
References: <20231122143603.85297-1-sxwjean@me.com>
 <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz>
 <CAB=+i9Rw2Cm1SEYJu8oLBBxy-gaTLty64buma+FHs81pkSQz6w@mail.gmail.com>
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <CAB=+i9Rw2Cm1SEYJu8oLBBxy-gaTLty64buma+FHs81pkSQz6w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

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
>>