[PATCH v8 0/2] mm/vmscan: select the closest preferred node in demote_folio_list()

[Bing Jiao <bingjiao@google.com>]

[Patch v7 2/2] tries to traverse the demotion targets hierarchically
until a preferred node within mems_allowed is found.

However, node_demotion[node].preferred may not contain all nodes in the
next memory tier. For example, in the below typograph:

  Top-tier  Node 0 ---- Node 1
             |            |
             |            |
  Far-tier  Node 2      Node 3

node_demotion[0].preferred: [2]
node_demotion[1].preferred: [3]
node_demotion[2].preferred: []
node_demotion[3].preferred: []

If mems_allowed is [3], demote_folio_list() cannot find a valid demotion
target when demoting pages from Node 0. Because next_demotion_node(0)
returns Node 2 and [2], which are not in mems_allowed; the second call
to next_demotion_node(2) returns NUMA_NO_NODE.

This patch uses find_next_best_node() to find the closest node when all
preferred nodes are not in mems_allowed, mimicking the logic
of establish_demotion_targets().


Hi Andrew,

Could you please remove Commit fd8cb9a8cedc ("mm/vmscan: select the closest
preferred node in demote_folio_list()") and Commit 127714c76c46
("mm/vmscan: fix uninitialized variable in demote_folio_list()") from
the mm-unstable branch, as this patch serves as a full replacement for
both.

I suggest allowing some time for this to be thoroughly reviewed in case
there are any remaining edge cases or issues I overlooked.

Because no modifications to [Patch v7 1/2], I did not attach a new
version of it.

Thanks!

Best regards,
Bing

Bing Jiao (1):
  mm/vmscan: select the closest preferred node in demote_folio_list()

 include/linux/memory-tiers.h |  6 +++---
 mm/memory-tiers.c            | 11 +++++++----
 mm/vmscan.c                  | 30 +++++++++++++++++++++++-------
 3 files changed, 33 insertions(+), 14 deletions(-)

--
2.52.0.457.g6b5491de43-goog