On 6/10/26 12:41, Gregory Price wrote: > On Wed, Jun 03, 2026 at 03:00:01PM +1000, Balbir Singh wrote: >>> >>> __GFP_THISNODE cannot be overloaded to do anything useful here. >> >> Let me clarify, I meant to say, let's use a nodemask for allocation >> and __GFP_THISNODE gets us to the node we desire, if that is the only >> node. My earlier comment might not have been clear. >> > > I've been tested an stripped back patch set where I drop all FALLBACK > entries for private nodes (including for itself) and only keep the > NOFALLBACK entry for private nodes. > > This effectively isolates the nodes for any allocation without > __GFP_THISNODE. > > This also precludes these nodes from ever using non-mbind mempolicies, > which I think is a completely reasonable compromise and something I was > already expecting we would do. > > Notably: slub.c injects __GFP_THISNODE internally on behalf of kmalloc, > which causes spillage into private nodes because slub allows private > nodes in its mask. I think this is fixable. > > I have to inspect some other __GFP_THISNODE users (hugetlb, some arch > code, etc), but it seems like fully dropping the FALLBACK entries and > requiring __GFP_THISNODE might be sufficient.
Sorry, I haven't been able to follow up so far, and not sure if that's what you are discussing here ... After the LSF/MM session, I was wondering, whether if we focus on allowing only folios allocations to end up on private memory nodes for now: could the __GFP_THISNODE approach work there? Essentially, disallow any allocations on non-folio paths, and allow folio allocation only with __GFP_THISNODE set. I have to find time to read the other mails in this thread, on my todo list. So sorry if that is precisely what is being discussed here. -- Cheers, David
