Re: [Lsf-pc] [LSF/MM/BPF TOPIC][RFC PATCH v4 00/27] Private Memory Nodes (w/ Compressed RAM)

[Vlastimil Babka (SUSE)]

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