Re: [PATCH v9 01/10] memblock: Introduce MEMBLOCK_LLMAP

[Thierry Reding <thierry.reding@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Tue, Sep 08, 2026 at 10:40:16AM +0300, Mike Rapoport wrote:
> On Mon, Sep 07, 2026 at 10:50:12AM +0100, Vincent Donnefort wrote:
> > On Sun, Sep 06, 2026 at 10:33:11PM +0300, Mike Rapoport wrote:
> > > On Wed, Sep 02, 2026 at 11:47:03AM +0100, Vincent Donnefort wrote:
> > > > Keeping last-level mappings is interesting on some architectures as it
> > > > allows mapping/unmapping pages from the kernel direct map without the
> > > > risk of splitting blocks which, under the break-before-make rule, may
> > > > trigger page-faults the kernel can't handle.
> > > > 
> > > > However, mapping the entire direct map at PTE-level is costly. So
> > > > instead, create a new memblock flag MEMBLOCK_LLMAP to enable the system
> > > 
> > > I believe MEMBLOCK_PTE_MAP sounds more descriptive.
> > 
> > The idea was to have something close from NOMAP, to emphasis it is one or the
> > other. But PTE_MAP sounds good too.
> 
> Could be PTEMAP if you prefer.
> My point was that unlike PTE, "LL" is not perceived as last-level, it
> should be looked up.

We were discussing the concept of enabling entire block mappings to be
removed at once from the linear map, so at that point "PTE"MAP may no
longer be accurate.

I imagine that in some scenarios we might be able to go to PUD mappings
for something like VPR (say systems with a fair amount of system memory
and we want to carve out 4 GiB for VPR, split into four 1 GiB chunks).

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]