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

[Nick Huang]

Lorenzo Stoakes <ljs@xxxxxxxxxx> 於 2026年4月19日週日 下午9:17寫道：
>
> On Sun, Apr 19, 2026 at 10:35:44AM +0200, David Hildenbrand (Arm) wrote:
> > On 4/18/26 18:15, Matthew Wilcox wrote:
> > > On Sat, Apr 18, 2026 at 10:07:22AM +0100, Lorenzo Stoakes wrote:
> > >> 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)
> > >>
> > >> The fact you're insanely wrong about the current state of slab only makes this
> > >> worse.
> > >
> > > This is actually a new low.  We've always had to contend with people
> > > putting up outdated or just wrong information on web pages, and there's
> > > little we can do about it.  Witness all the outdated information about
> > > THP that's based on code that's been deleted for over a decade.
> > >
> > > But now we've got AI trained on all this wrong/ out of date information,
> > > and, er, "enthusiasts" who are trying to change the correct information
> > > in the kernel to match what the deluded AI "thinks" should be true.
> > >
> > > Let that sink in.
>
> Ugh ye gawds. My attitude is nip this in the bud early.
>
> I'm very harsh in response to these things for a reason - firstly, it's rude,
> obnoxious + disrespectful, so a negative response is wholly appropriate.
>
> But more importantly, I want to SET A PRECEDENT that if you send this crap
> you'll get a VERY negative response.
>
> Clueless but good faith or bad faith - it's straight up plagiarism and that's
> totally unacceptable.
>
> > >
> >
> > I think we should make it very clear that we don't want doc updates from someone
> > that is not a renowned expert in that area or wants to become an expert in that
> > area (and already discussed working on the docs with maintainers/experts).
> >
> > Otherwise we'll have this same discussion over and over again.
> >
> > diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
> > index 7aa2a88869083..8c5721001c8bb 100644
> > --- a/Documentation/mm/index.rst
> > +++ b/Documentation/mm/index.rst
> > @@ -7,6 +7,11 @@ of Linux.  If you are looking for advice on simply allocating
> > memory,
> >   see the :ref:`memory_allocation`.  For controlling and tuning guides,
> >   see the :doc:`admin guide <../admin-guide/mm/index>`.
> >
> > +A lot of documentation in this guide is still incomplete. If you are not
> > +a renowned expert in the specific area, but you want to contribute bigger
> > +chunks of documentation, talk to the respective MM experts first. LLM
> > +generated slop from non-experts will be rejected without further comments.
> > +
> >   .. toctree::
> >      :maxdepth: 1
> >
> >
> >
> > LLMs are just the tip of the iceberg. It will all be developmend-by review with
> > inexperienced contributors. And we are only willing to put in the effort to
> > teach contributors if the contributors are not actually worth our time: i.e.,
> > LLM kiddies that will actually stick around and help the subsystem in the long run.
> >
> >
> > The whole doc update stuff is similar to people just grepping for TODOs in the
> > kernel and then using an LLM to produce code they have no idea about.
> >
> > It's the evolution of typo fixes: review load without any benefit.
>
> Agree with all of that!
>
> Let's do that, happy to give tags on a patch for the above :)
>
> >
> > --
> > Cheers,
> >
> > David
> >
>
> Cheers, Lorenzo
Hi Lorenzo Stoakes


I am really sorry for causing trouble for everyone. I would like to
ask which aspect of mine was disrespectful, so that I can be more
careful next time.

If I want to make this kind of change, should I send an [RFC patch] to
ask for everyone's opinion?

Sorry, I really am not very clear about the process.
-- 
Regards,
Nick Huang