On 6/15/26 17:37, Gregory Price wrote: > 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.
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
