On 6/15/26 17:37, Gregory Price wrote:

On Mon, Jun 15, 2026 at 05:18:55PM +0200, David Hildenbrand (Arm) wrote:

quoted

On 6/15/26 16:38, Vlastimil Babka (SUSE) wrote:

quoted

I think the memalloc approach is dangerous due to unexpected nesting. There
might be nested page allocations in page allocation itself (due to some
debugging option). But also interrupts do not change what "current" points
to. Suddenly those could start requesting folios and/or private nodes and be
surprised, I'm afraid.

Yeah, we'd need some way to distinguish the main allocation from these other
(nested) allocations.

quoted

The memalloc scopes only work well when they restrict the context wrt
reclaim, and allocations in IRQ have to be already restricted heavily
(atomic) so further memalloc restrictions don't do anything in practice. But
to make them change other aspects of the allocations like this won't work.

I was assuming that memalloc_pin_save() would already violate that, but really
it only restricts where movable allocations land, and that doesn't matter for
other kernel allocations.

Do you see any other way to make something like an allocation context work, and
avoid introducing more GFP flags?

One thought would be a way to switch what fallback list is used, and
then have specific fallback lists for certain contexts.

Right now there is a single example of this: __GFP_THISNODE
  |= __GFP_THISNODE   =>  NOFALLBACK
  &= ~__GFP_THISNODE  =>  FALLBACK

We could add an interface with the desired fallback list based as an
argument, and let get_page_from_freelist to prefer that over the default
global lists.

Does it mean a new argument in a number of functions in the page allocator,
or can it be mapped to alloc_flags (at least internally?), because the
number of possible fallback lists is small enough?

Omit all special nodes from FALLBACK/NOFALLBACK and make the special
contexts provide the fallback-base that should be used.

On my current branch i think that would include modifying, in totality:

   alloc_folio_mpol()
   alloc_demotion_folio()
   alloc_migration_target()

And i'm pretty sure that all just nests nicely.

We might not even need memalloc... hmmm

~Gregory