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

[Mike Rapoport]

On Tue, Sep 08, 2026 at 11:18:53AM +0200, Thierry Reding wrote:
> 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).

_LEAFMAP then? ;-)
 
> Thierry



-- 
Sincerely yours,
Mike.