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

[David Hildenbrand (Arm)]

On 9/12/26 05:04, Gregory Price wrote:
> find_next_best_node() picks the next-closest node for a fallback list
> from the full N_MEMORY set. Refactor it into find_next_best_node_in(),
> which takes an explicit candidates nodemask.
> 
> This enables building fallback lists with non-N_MEMORY candidates.
> 
> No functional change: every caller still selects from N_MEMORY.
> 
> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
> Acked-by: Balbir Singh <balbirs@xxxxxxxxxx>
> Signed-off-by: Gregory Price <gourry@xxxxxxxxxx>
> ---
>  mm/internal.h     |  6 ++++--
>  mm/memory-tiers.c |  7 ++++---
>  mm/page_alloc.c   | 13 ++++++++-----
>  3 files changed, 16 insertions(+), 10 deletions(-)
> 
> 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?


-- 
Cheers,

David