include/linux/cpuset.h | 6 ++-- include/linux/memcontrol.h | 6 ++-- include/linux/memory-tiers.h | 6 ++-- kernel/cgroup/cpuset.c | 54 ++++++++++++++++++++++++------------ mm/memcontrol.c | 16 +++++++++-- mm/memory-tiers.c | 21 ++++++++++---- mm/vmscan.c | 31 +++++++++++++-------- 7 files changed, 95 insertions(+), 45 deletions(-)
This patch series addresses two issues in demote_folio_list(),
can_demote(), and next_demotion_node() in reclaim/demotion.
1. demote_folio_list() and can_demote() do not correctly check demotion
target against cpuset.mems_effective, which will cause (a) pages are
demoted to not-allowed nodes and (b) pages are failed to demote even
if the system still have allowed demotion nodes.
Patch 1 fixes this bug by update cpuset_node_allowed() and
mem_cgroup_node_allowed() to return effective_mems, allowing directly
logic-and operation against demotion targets.
2. next_demotion_node() returns a preferred demotion target, but it does
check the node against allowed nodes.
Patch 2 ensures that next_demotion_node() filters against the allowed
node mask and selects the closest demotion target to the source node.
===
Hi Andrew,
Sorry for the extra noise in your inbox.
I’m resubmitting the full refreshed patch series together this time.
I just realized it is better to include the unmodified patches alongside
the modified ones to ensure compatibility with upstream automated tools
and to simplify your review process.
The refreshed patch series replaces some commits in mm-untable,
including:
- Commit 809cc3db1831 ("mm/vmscan: fix demotion targets checks in
reclaim/demotion")
- Commit fd8cb9a8cedc ("mm/vmscan: select the closest preferred node
in demote_folio_list()")
- Commit 127714c76c46 ("mm/vmscan: fix uninitialized variable in
demote_folio_list()")
Thanks!
Best regards,
Bing
Bing Jiao (2):
mm/vmscan: fix demotion targets checks in reclaim/demotion
mm/vmscan: select the closest perferred node in demote_folio_list()
include/linux/cpuset.h | 6 ++--
include/linux/memcontrol.h | 6 ++--
include/linux/memory-tiers.h | 6 ++--
kernel/cgroup/cpuset.c | 54 ++++++++++++++++++++++++------------
mm/memcontrol.c | 16 +++++++++--
mm/memory-tiers.c | 21 ++++++++++----
mm/vmscan.c | 31 +++++++++++++--------
7 files changed, 95 insertions(+), 45 deletions(-)
--
2.52.0.457.g6b5491de43-goog
Hi Bing, Please don't reply (i.e. use In-Reply-To) to older revision of your series. Send each revision independently. On Wed, Jan 14, 2026 at 08:53:01PM +0000, Bing Jiao wrote: > This patch series addresses two issues in demote_folio_list(), > can_demote(), and next_demotion_node() in reclaim/demotion. > > 1. demote_folio_list() and can_demote() do not correctly check demotion > target against cpuset.mems_effective, which will cause (a) pages are > demoted pages to be demoted > to not-allowed nodes and (b) pages are failed to demote page fail to demote > even > if the system still have allowed demotion nodes. > > Patch 1 fixes this bug by update updating > cpuset_node_allowed() and > mem_cgroup_node_allowed() to return effective_mems, allowing directly > logic-and operation against demotion targets. > > 2. next_demotion_node() returns a preferred demotion target, but it does does or does not? > check the node against allowed nodes. > > Patch 2 ensures that next_demotion_node() filters against the allowed > node mask and selects the closest demotion target to the source node. >
On Fri, Jan 30, 2026 at 03:35:26PM -0800, Shakeel Butt wrote: > Hi Bing, > > Please don't reply (i.e. use In-Reply-To) to older revision of your > series. Send each revision independently. > > On Wed, Jan 14, 2026 at 08:53:01PM +0000, Bing Jiao wrote: > > This patch series addresses two issues in demote_folio_list(), > > can_demote(), and next_demotion_node() in reclaim/demotion. > > > > 1. demote_folio_list() and can_demote() do not correctly check demotion > > target against cpuset.mems_effective, which will cause (a) pages are > > demoted > > pages to be demoted > > > to not-allowed nodes and (b) pages are failed to demote > > page fail to demote > > > even > > if the system still have allowed demotion nodes. > > > > Patch 1 fixes this bug by update > > updating > > > cpuset_node_allowed() and > > mem_cgroup_node_allowed() to return effective_mems, allowing directly > > logic-and operation against demotion targets. > > > > 2. next_demotion_node() returns a preferred demotion target, but it does > > does or does not? > > > check the node against allowed nodes. > > > > Patch 2 ensures that next_demotion_node() filters against the allowed > > node mask and selects the closest demotion target to the source node. Hi Shakeel, Thank you for taking the time to review this patch series and for the helpful corrections. I also appreciate the reminder about the patch replying rule and will make sure to send future revisions independently. Have a great weekend! Best, Bing
On Wed, 14 Jan 2026 20:53:01 +0000 Bing Jiao <bingjiao@google.com> wrote: > I’m resubmitting the full refreshed patch series together this time. > I just realized it is better to include the unmodified patches alongside > the modified ones to ensure compatibility with upstream automated tools > and to simplify your review process. No probs. [1/2] is cc:stable whereas [2/2] is not. Ordinarily that means I must split the series apart (they take different routes) and often discard the [0/n]. In this case I think I'll leave things as-is, so [1/2]'s entry into the -stable pipeline will occur a few weeks later. I don't think the problem is serious enough to need super-fast-tracking? Hopefully this approach means we'll get some Reviewed-bys ;)
On Thu, Jan 15, 2026 at 04:00:11PM -0800, Andrew Morton wrote: > On Wed, 14 Jan 2026 20:53:01 +0000 Bing Jiao <bingjiao@google.com> wrote: > > > I’m resubmitting the full refreshed patch series together this time. > > I just realized it is better to include the unmodified patches alongside > > the modified ones to ensure compatibility with upstream automated tools > > and to simplify your review process. > > No probs. > > [1/2] is cc:stable whereas [2/2] is not. Ordinarily that means I must > split the series apart (they take different routes) and often discard > the [0/n]. Hi Andrew, Thank you for the explanation. I appreciate the insight into the upstream process and the time you have taken to review this series. I wish I had known this earlier so as not to add to your workload. > In this case I think I'll leave things as-is, so [1/2]'s entry into the > -stable pipeline will occur a few weeks later. I don't think the > problem is serious enough to need super-fast-tracking? > > Hopefully this approach means we'll get some Reviewed-bys ;) I agree that the issue does not require urgent fast-tracking, so leaving the series as-is for the standard pipeline is appropriate. Best regards, Bing
© 2016 - 2026 Red Hat, Inc.