From: Mike Rapoport <rppt@kernel.org>
To: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
Cc: Kit Dallege <xaum.io@gmail.com>,
akpm@linux-foundation.org, david@kernel.org, corbet@lwn.net,
linux-mm@kvack.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] Docs/mm: document Boot Memory
Date: Mon, 16 Mar 2026 08:47:17 +0200 [thread overview]
Message-ID: <abendSlwDIwB4teF@kernel.org> (raw)
In-Reply-To: <0c981733-477b-496e-abe5-54eebaae04b1@lucifer.local>
On Sun, Mar 15, 2026 at 08:43:24PM +0000, Lorenzo Stoakes (Oracle) wrote:
> NAK for being AI slop, again, obviously.
>
> +cc Mike, the 'boot memory' maintainer, who again I'm sure will be
> overjoyed by this.
I'm not going to review it thoroughly because
"maintainers are entitled to reject your series without detailed review"
> Reasons, as the rest:
> - Worthless documentation
> - Everything about patch screams 'zero effort, Claude did it all'
> - Bad etiquette
>
> On Sat, Mar 14, 2026 at 04:25:27PM +0100, Kit Dallege wrote:
> > Fill in the bootmem.rst stub created in commit 481cc97349d6
> > ("mm,doc: Add new documentation structure") as part of
> > the structured memory management documentation following
> > Mel Gorman's book outline.
We don't need to fill in missing parts just to fill files with contents, we
need quality documentation.
This doc does not improve over what we already have in
Documentation/core-api/boot-time-mm.rst.
...
> > +The memblock allocator fills this role, managing physical memory from the
> > +earliest stages of boot until the buddy allocator takes over. The
> > +implementation is in ``mm/memblock.c`` and ``mm/mm_init.c``.
>
> This is at least reasonable.
But still wrong. mm_init.c is not a part of memblock allocator.
> > +- ``kernelcore=`` sets the amount of memory that must be in non-movable
> > + zones.
> > +- ``movablecore=`` sets the amount of memory to place in ``ZONE_MOVABLE``.
> > +- ``movable_node`` allows entire NUMA nodes to be treated as movable.
> > +- ``kernelcore=mirror`` restricts non-movable memory to mirrored regions.
> > +
> > +These parameters control the boundary between ``ZONE_MOVABLE`` and the
> > +other zones, which in turn affects how much memory is available for
> > +transparent huge pages, memory hot-remove, and CMA.
Oh, my ...
How CMA and THP are related to ZONE_MOVABLE here?!
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2026-03-16 6:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-14 15:25 [PATCH] Docs/mm: document Boot Memory Kit Dallege
2026-03-15 20:43 ` Lorenzo Stoakes (Oracle)
2026-03-16 6:47 ` Mike Rapoport [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abendSlwDIwB4teF@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=xaum.io@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox