On Fri, Nov 24, 2023 at 8:24 PM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 11/22/23 15:36, sxwjean@xxxxxx wrote: > > From: Xiongwei Song <xiongwei.song@xxxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxxx> > > --- > > v2: Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx> 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@xxxxxx/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 >
