Thread (26 messages) flat view 26 messages, 5 authors, 6d ago

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

From: Thierry Reding <thierry.reding@kernel.org>
Date: 2026-09-08 09:19:13
Also in: linux-devicetree, linux-mm, lkml, op-tee

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:
quoted
On Sun, Sep 06, 2026 at 10:33:11PM +0300, Mike Rapoport wrote:
quoted
On Wed, Sep 02, 2026 at 11:47:03AM +0100, Vincent Donnefort wrote:
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help