[RFC PATCH 0/6] mm: pass alloc_flags through folio, filemap, and bulk allocators

Gregory Price posted 6 patches 16 hours ago
mm/filemap.c    |  45 ++++++++--
mm/mempolicy.c  |  44 +++++++---
mm/mempolicy.h  |  28 +++++++
mm/page_alloc.c | 217 ++++++++++++++++++++++++++++--------------------
mm/page_alloc.h |  10 +++
5 files changed, 236 insertions(+), 108 deletions(-)
create mode 100644 mm/mempolicy.h
[RFC PATCH 0/6] mm: pass alloc_flags through folio, filemap, and bulk allocators
Posted by Gregory Price 16 hours ago
The folio, filemap, and bulk allocation interfaces currently hard-code
ALLOC_DEFAULT before reaching the page allocator. Multiple MM series
need to select allocator behavior through these paths, so pulling these
changes out ahead helps both series avoid conflicts.

This six-patch series first separates allocator behavior flags from
the bulk allocator fast-path flags and shares their validation and
preparation. It then passes alloc_flags through the MM-internal folio,
NUMA policy, filemap, and bulk helpers.

The existing exported folio, node, filemap, and bulk interfaces remain
ALLOC_DEFAULT wrappers.

Non-task ALLOC_NOLOCK folio allocations bypass task mempolicy and
cpuset-spread selection because those paths are not safe in all
interrupt contexts.

Existing callers retain their current behavior.

The allocator changes were built for x86-64 with DEBUG_VM,
DEBUG_VM_PGFLAGS, DEBUG_PAGEALLOC, PAGE_OWNER, PAGE_TABLE_CHECK,
PROVE_LOCKING, DEBUG_ATOMIC_SLEEP, and memory allocation profiling enabled.

Testing under virtme-ng/QEMU used a four-CPU guest:

- test_vmalloc vm_map_ram passed 50/50 64-page batches and 100/100 one-page
  fallbacks.
- With page_owner=on, all 25 runs produced the expected partial batch because
  page owner deliberately uses the one-page fallback.
- The alloc_tag ioctl selftest passed 4/4 tests.
- The migration selftest passed 6/6 tests.
- The page-fragment smoke, aligned, and nonaligned tests passed 3/3.
- khugepaged -s 2 passed 22 non-swap tests. Its four swap-dependent tests
  reported failure because the guest had no swap configured.

No BUG, WARNING, lockdep, or atomic-sleep diagnostics were reported.

Cc: Vlastimil Babka <vbabka@kernel.org>

Brendan Jackman (3):
  mm/page_alloc: add an alloc_flags-aware folio allocator
  mm/mempolicy: plumb alloc_flags through folio allocation
  mm/filemap: plumb alloc_flags through folio allocation

Gregory Price (3):
  mm/page_alloc: clarify bulk allocator flag scope
  mm/page_alloc: refactor alloc_flags preparation
  mm/page_alloc: let the bulk allocator carry alloc_flags

 mm/filemap.c    |  45 ++++++++--
 mm/mempolicy.c  |  44 +++++++---
 mm/mempolicy.h  |  28 +++++++
 mm/page_alloc.c | 217 ++++++++++++++++++++++++++++--------------------
 mm/page_alloc.h |  10 +++
 5 files changed, 236 insertions(+), 108 deletions(-)
 create mode 100644 mm/mempolicy.h

-- 
2.55.0
Re: [RFC PATCH 0/6] mm: pass alloc_flags through folio, filemap, and bulk allocators
Posted by Matthew Wilcox 15 hours ago
On Wed, Sep 23, 2026 at 05:10:34PM -0400, Gregory Price wrote:
> The folio, filemap, and bulk allocation interfaces currently hard-code
> ALLOC_DEFAULT before reaching the page allocator. Multiple MM series
> need to select allocator behavior through these paths, so pulling these
> changes out ahead helps both series avoid conflicts.

I really think this 'expose ALLOC flags' idea is wrong.
Re: [RFC PATCH 0/6] mm: pass alloc_flags through folio, filemap, and bulk allocators
Posted by Gregory Price 15 hours ago
On Wed, Sep 23, 2026 at 10:42:07PM +0100, Matthew Wilcox wrote:
> On Wed, Sep 23, 2026 at 05:10:34PM -0400, Gregory Price wrote:
> > The folio, filemap, and bulk allocation interfaces currently hard-code
> > ALLOC_DEFAULT before reaching the page allocator. Multiple MM series
> > need to select allocator behavior through these paths, so pulling these
> > changes out ahead helps both series avoid conflicts.
> 
> I really think this 'expose ALLOC flags' idea is wrong.

It is mm/ internal only - to be clear.

It's also already been partially exposed, this just brings the rest of
the interfaces with it.

There are use cases.  I initially only wanted to expose a zonelist
selection rather than alloc flags, but given ALLOC_UNMAPPED was
in-flight it seemed better not to propose different solutions when there
are existing possibilities.

I'm open to options.

~Gregory