On Mon, Jun 15, 2026 at 05:18:55PM +0200, David Hildenbrand (Arm) wrote: > On 6/15/26 16:38, Vlastimil Babka (SUSE) wrote: > > > > 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. > > > > > > 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. 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
