Re: [PATCH v2 1/2] mm: refactor find_next_best_node to find_next_best_node_in

[Gregory Price]

On Fri, Sep 18, 2026 at 10:42:12PM +0200, David Hildenbrand (Arm) wrote:
> > diff --git a/mm/internal.h b/mm/internal.h
> > index da14c56fb24e..1519dd21a900 100644
> > --- a/mm/internal.h
> > +++ b/mm/internal.h
> > @@ -1133,7 +1133,8 @@ extern int node_reclaim_mode;
> >  
> >  extern unsigned long node_reclaim(struct pglist_data *pgdat,
> >  				  gfp_t gfp_mask, unsigned int order);
> > -extern int find_next_best_node(int node, nodemask_t *used_node_mask);
> > +int find_next_best_node_in(int node, nodemask_t *used_node_mask,
> > +		const nodemask_t *candidates);
> 
> Just curious, for your use case, wouldn't it be enough to pass N_MEMORY?
> 
> Or do we expect to pass other actual node masks that are not derived from
> node_states?
> 

That is the base case today - and in fact that's what's hard-coded
in the current logic.

For the private node series we will pass:

ZONELIST_FALLBACK:  N_MEMORY_GENERAL    /* general purpose nodes */

ZONELIST_PRIVATE:   N_MEMORY            /* All nodes, including private */

ZONELIST_KTEST:     (N_MEMORY_GENERAL ^ N_MEMORY)  /* private only */


the ZONELIST_KTEST is something i'm still working with - but it gives us
fully isolated pgdat structures that allow a KTEST to treat the node
mutations as determinstic and otherwise unreachable by the kernel
(because the kernel outside ktest can't select ZOENLIST_KTEST).


ANYWAY...

I don't expect us to build hundreds of these zonelists - they are
expensive to construct (space-wise), but that's largely because we
haven't needed to optimize it.

But you could imagine having a custom zonelist built on a subset
of N_MEMORY so that you could do like...

for_each_reclaimable_zone(z) {
	/* Reclaim */
}

and hide all this nasty zone business from other components of mm/ that
really don't need all that complexity (at most they want the LRUs).

~Gregory