On Wed, Jun 10, 2026 at 06:41:57AM -0400, 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. >
Agreed. > 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. > > ~Gregory That's good progress, thanks for the update! Balbir
