支持分配非直接映射页 · v3

Hi Brendan, On Sun, Jul 26, 2026 at 10:22:34PM +0000, Brendan Jackman wrote: > From: Nikita Kalyazin nikita.kalyazin@linux.dev > > Let’s provide folio_{zap,restore}_direct_map helpers as preparati

On Sun, Jul 26, 2026 at 10:22:35PM +0000, Brendan Jackman wrote: > From: Nikita Kalyazin nikita.kalyazin@linux.dev > > Replace set_direct_map_*_noflush with newly available > folio_zap_direct_map c

From: Patrick Roy patrick.roy@linux.dev Add AS_NO_DIRECT_MAP for mappings where direct map entries of folios are set to not present. Currently, mappings that match this description are secretmem ma

This code will be needed elsewhere in a following patch. Split out the trivial code move for easy review. As a side effect, change the logging slightly: instead of directly reporting the level of the

In a subsequent patch these defines will need to be referenced from a new file, move them as a separate patch for easy review. The comments have style violations (personal pronouns etc), do not fix t

In commit bfe3d8f6313d (“x86/tlb: Restrict access to tlbstate”) some low-level logic (the important detail here is flush_tlb_info) was hidden from modules, along with functions associated with that da

Various security features benefit from having process-local address mappings within the kernel. Examples include no-direct-map guest_memfd [2] and significant optimizations for ASI [1]. With the curr

Now that x86 processes have a general mm-local region, the LDT-specific management of the higher-level pagetables can mostly be replaced by just using the generic mm-local API. Drop all management of

Preparatory patch, no functional change intended. To prepare for making this function more generic, convert the boolean “create” arg into a flags arg with a single flag that has the same meaning. Si

Add two flags to make this API more generic: 1. Separate “create” into two levels - one to allow creating new mappings without allocating pagetables, and one for the current behaviour that allo

The mermap provides a fast way to create ephemeral mm-local mappings of physical pages. The purpose of this is to access pages that have been removed from the direct map. Potential use cases are: 1.

Some simple smoke-tests for the mermap. Mainly aiming to test: 1. That there aren’t any silly off-by-ones. 2. That the pagetables are not completely broken. 3. That the TLB appears to get flushed b

This is preparation for teaching the page allocator to break up free pages according to properties that have nothing to do with mobility. For example it can be used to allocate pages that are non-pres

Since migratetypes are a sub-element of freetype, move the pure definitions into the new freetype.h. This will enable referring to these raw types from pageblock-flags.h. Acked-by: Vlastimil Babka (

Freetypes are currently just a wrapper for migratetypes, but in a later patch they will gain flags. The theoretically possible space of freetypes will thus grow, but many freetypes will not actually b

Create ALLOC_UNMAPPED, which requests pages that are not present in the direct map. Since this feature has a cost (e.g. more freelists), it’s behind a kconfig. Unlike other conditionally-defined alloc

In preparation for implementing allocation from FREETYPE_UNMAPPED lists. Since it works nicely with the existing allocator logic, and also offers a simple way to amortize TLB flushing costs, ALLOC_UN

The normal freelists are already separated by this flag, so now update the pcplists accordingly. This follows the most “obvious” design where ALLOC_UNMAPPED is supported at arbitrary orders. If neces

Commit 1ebbb21811b7 (“mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations accesses reserves”) renamed ALLOC_HARDER to ALLOC_NON_BLOCK because the former is “a vague description”.

This flag is set unless we can be sure the caller isn’t in an atomic context. The allocator will soon start needing to call set_direct_map_* APIs which cannot be called with IRQs off. It will need to

Currently FREETYPE_UNMAPPED allocs will always fail because, although the lists exist to hold them, there is no way to actually create an unmapped page block. This commit adds one, and also the logic

Add a simple smoke test for ALLOC_UNMAPPED that tries to exercise flipping pageblocks between mapped/unmapped state. Also add some basic tests for some freelist-indexing helpers. Simplest way to run

In order to infer whether compaction is likely to enable an allocation that maps/unmaps a pageblock, we need to know how many fully-free pageblocks of each type there are. Signed-off-by: Brendan Jack

This is the minimal solution for ensuring that compaction can service unmapped allocations. Without this, it’s possible for compaction to just check watermarks and see plenty of free pages, without be

A subsequent patch will want to set ALLOC_UNMAPPED in the allocator APIs used by filemap.c. To keep that patch from getting overwhelming, split out the arg plumbing into a separate one. No functional

Currently AS_NO_DIRECT_MAP maps and unmaps pages on-demand, which means there is no control over the batching of TLB flushes. Where it’s supported, this patch switches it to use ALLOC_UNMAPPED instead