Re: [PATCH] docs: Add overview and SLUB allocator sections to slab documentation

["Harry Yoo (Oracle)" <harry@kernel.org>]

Hi, Nick.

On Sat, Apr 18, 2026 at 12:06:19AM +0000, Nick Huang wrote:
> - Add "Overview" section explaining the slab allocator's role and purpose
> - Document the three main slab allocator implementations (SLAB, SLUB, SLOB)
> - Highlight SLUB as the default allocator on modern systems
> - Add "SLUB Allocator" subsection with detailed information:
> - Explain SLUB's design goals and advantages over legacy SLAB
> - Document its focus on simplification and performance
> - Note support for both uniprocessor and SMP systems
>
> Signed-off-by: Nick Huang <sef1548@gmail.com>
> --0

In case this was assisted by AI or other tools, please disclose that
according to the process document:

  https://docs.kernel.org/process/generated-content.html
  https://docs.kernel.org/process/coding-assistants.html

Mentioning because some people using tools to develop/document
the kernel are not aware that they need to disclose the fact.
It's better to remind people.

Tools can help only if, you, as a person, understand the design and
tradeoff behind it. I don't think it'd be useful to spend time on
improving document if this is driven by AI tools or something,
not you.

If you're using AI or not, the fact that you're not following recent
changes of the slab allocator worries me a little bit, to be honest.

Well-written design documentation is hard to come by without
understanding the current design.

If you're still willing to improve the doc, please do more research.

>  Documentation/mm/slab.rst | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/mm/slab.rst b/Documentation/mm/slab.rst
> index 2bcc58ada302..2d1d093afb7b 100644
> --- a/Documentation/mm/slab.rst
> +++ b/Documentation/mm/slab.rst
> @@ -4,6 +4,32 @@
> +SLUB Allocator
> +==============
> +
> +Overview
> +--------
> +
> +SLUB is a slab allocator designed to replace the legacy SLAB allocator

As Matthew mentioned, SLAB and SLOB were gone.
Also, it isn't really the traditional SLUB we have had anymore.

> +(mm/slab.c). It addresses the complexity, scalability limitations, and
> +memory overhead of the SLAB implementation.

Stating "Compared to SLAB, SLUB addresses X, Y, and Z" is
worth adding only if with a reason explaining why.

If you think SLUB addresses certain problems of SLAB, please explain
what problems are and why they exist, and how SLUB addresses that.

Please make more solid arguments with explanations to support.

> +The primary goal of SLUB is to simplify slab allocation while improving

I don't think traditional SLUB was particularily simple compared
to SLAB, to be honest. It was probably simple at the beginning,
but then more and more complexity has been added later.

> +performance on both uniprocessor (UP) and symmetric multiprocessing (SMP)
> +systems.

SLAB also supported UP and had features to provide scalability on
SMP. Why do you think SLUB particularly improved performance on
them?

> +
>  Functions and structures
>  ========================

-- 
Cheers,
Harry / Hyeonggon