Re: [PATCH v1 0/2] mm/vmscan: optimize preferred target demotion node selection

[Joshua Hahn <joshua.hahnjy@gmail.com>]

On Wed,  7 Jan 2026 07:28:12 +0000 Bing Jiao <bingjiao@google.com> wrote:

Hello Bing, thank you for your patch!

I have a few questions about the motivation about this patch.

> In tiered memory systems, the demotion aims to move cold folios to the
> far-tier nodes. To maintain system performance, the demotion target
> should ideally be the node with the shortest NUMA distance from the
> source node.
>
> However, the current implementation has two suboptimal behaviors:
> 
> 1. Unbalanced Fallback: When the primary preferred demotion node is full,
>    the allocator falls back to other nodes in a way that often skews
>    toward zones that closer to the primary preferred node rather than
>    distributing the load evenly across fallback nodes.

I definitely think this is a problem that can exist for some workloads /
machines, and I agree that there should be some mechanism to manage this
in the demotion code as well. In the context of tiered memory, it might be
the case that some far-nodes have more restrited memory bandwidth, so better
distribution of memory across those nodes definitely sounds like something
that should at least be considered (even if it might not be the sole factor).

With that said, I think adding some numbers here to motivate this change could
definitely make the argument more convincing. In particular, I don't think
I am fully convinced that doing a full random selection from the demotion
targets makes the most sense. Maybe there are a few more things to consider,
like the node's capacity, how full it is, bandwidth, etc. For instance,
weighted interleave auto-tuning makes a weighted selection based on each
node's bandwidth.

At least right now, it seems like we're consistent with how the demotion node
gets selected when the preferred node is full.

Do your changes lead to a "better" distribution of memory? And does this
distribution lead to increased performance? I think some numbers here could
help my understanding and convince others as well : -)

> 2. Suboptimal Target Selection: demote_folio_list() randomly select
>    a preferred node from the allowed mask, potentially selecting
>    a very distant node.

Following up, I think it could be helpful to have a unified story about how
demotion nodes should be selected. In particular, I'm not entirely confident
if it makes sense to have a "try on the preferred demotion target, and then
select randomly among all other nodes" story, since these have conflicting
stories of "prefer close nodes" vs "distribute demotions". To put it explicitly,
what makes the first demotion target special? Should we just select randomly
for *all* demotion targets, not just if the preferred node is full?

Sorry if it seems like I am asking too many questions, I just wanted to get
a better understanding of the motivation behind the patch.

Thank you, and I hope you have a great day!
Joshua