The quilt patch titled
Subject: mm/numa_balancing: allow migrate on protnone reference with MPOL_PREFERRED_MANY policy
has been removed from the -mm tree. Its filename was
mm-numa_balancing-allow-migrate-on-protnone-reference-with-mpol_preferred_many-policy.patch
This patch was dropped because an updated version will be merged
------------------------------------------------------
From: Donet Tom <donettom@xxxxxxxxxxxxx>
Subject: mm/numa_balancing: allow migrate on protnone reference with MPOL_PREFERRED_MANY policy
Date: Sat, 17 Feb 2024 01:31:35 -0600
commit bda420b98505 ("numa balancing: migrate on fault among multiple
bound nodes") added support for migrate on protnone reference with
MPOL_BIND memory policy. This allowed numa fault migration when the
executing node is part of the policy mask for MPOL_BIND. This patch
extends migration support to MPOL_PREFERRED_MANY policy.
Currently, we cannot specify MPOL_PREFERRED_MANY with the mempolicy flag
MPOL_F_NUMA_BALANCING. This causes issues when we want to use
NUMA_BALANCING_MEMORY_TIERING. To effectively use the slow memory tier,
the kernel should not allocate pages from the slower memory tier via
allocation control zonelist fallback. Instead, we should move cold pages
from the faster memory node via memory demotion. For a page allocation,
kswapd is only woken up after we try to allocate pages from all nodes in
the allocation zone list. This implies that, without using memory
policies, we will end up allocating hot pages in the slower memory tier.
MPOL_PREFERRED_MANY was added by commit b27abaccf8e8 ("mm/mempolicy: add
MPOL_PREFERRED_MANY for multiple preferred nodes") to allow better
allocation control when we have memory tiers in the system. With
MPOL_PREFERRED_MANY, the user can use a policy node mask consisting only
of faster memory nodes. When we fail to allocate pages from the faster
memory node, kswapd would be woken up, allowing demotion of cold pages to
slower memory nodes.
With the current kernel, such usage of memory policies implies we can't do
page promotion from a slower memory tier to a faster memory tier using
numa fault. This patch fixes this issue.
For MPOL_PREFERRED_MANY, if the executing node is in the policy node mask,
we allow numa migration to the executing nodes. If the executing node is
not in the policy node mask but the folio is already allocated based on
policy preference (the folio node is in the policy node mask), we don't
allow numa migration. If both the executing node and folio node are
outside the policy node mask, we allow numa migration to the executing
nodes.
I have a test program which allocate memory on a specified node and
trigger the promotion or migration (Keep accessing the pages).
Without this patch if we set MPOL_PREFERRED_MANY promotion or migration
was not happening with this patch I could see pages are getting
migrated or promoted.
My system has 2 CPU+DRAM node (Tier 1) and 1 PMEM node(Tier 2). Below
are my test results.
In below table N0 and N1 are Tier1 Nodes. N6 is the Tier2 Node.
Exec_Node is the execution node, Policy is the nodes in nodemask and
"Curr Location Pages" is the node where pages present before migration
or promotion start.
Tests Results
------------------
Scenario 1:Â if the executing node is in the policy node mask
================================================================================
Exec_Node   Policy          Curr Location Pages Observations
================================================================================
N0Â Â Â Â Â Â Â Â Â Â N0 N1 N6Â Â Â Â Â Â Â Â Â Â Â Â N1 Pages Migrated from N1 to N0
N0Â Â Â Â Â Â Â Â Â N0 N1 N6Â Â Â Â Â Â Â Â Â Â Â N6 Pages Promoted from N6 to N0
N0Â Â Â Â Â Â Â Â Â N0 N1Â Â Â Â Â Â Â Â Â Â Â Â Â N1 Â Â Â Â Â Â Â Â Â Â Pages Migrated from N1 to N0
N0Â Â Â Â Â Â Â Â Â N0 N1Â Â Â Â Â Â Â Â Â Â Â Â Â Â N6 Â Â Pages Promoted from N6 to N0
Scenario 2: If the folio node is in policy node mask and Exec node not in policy node mask
================================================================================
Exec_Node   Policy      Curr Location Pages    Observations
================================================================================
N0Â Â Â Â Â Â Â Â N1 N6Â Â Â Â Â Â Â Â Â Â Â Â N1 Pages are not Migrating to N0
N0Â Â Â Â Â Â Â Â Â Â N1 N6Â Â Â Â Â Â Â Â Â Â Â Â N6 Pages are not migration to N0
N0Â Â Â Â Â Â Â Â Â Â Â N1Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â N1 Â Â Pages are not Migrating to N0
Scenario 3: both the folio node and executing node are outside the policy nodemask
==============================================================================
Exec_Node  Policy        Curr Location Pages      Observations
==============================================================================
N0Â Â Â Â Â Â Â Â N1Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â N6 Â Â Â Â Â Pages Promoted from N6 to N0
N0Â Â Â Â Â Â Â Â Â Â Â Â N6 N1Â Â Â Â Â Â Â Â Â Â Pages Migrated from N1 to N0
Link: https://lkml.kernel.org/r/8d7737208bd24e754dc7a538a3f7f02de84f1f72.1708097962.git.donettom@xxxxxxxxxxxxx
Signed-off-by: Aneesh Kumar K.V (IBM) <aneesh.kumar@xxxxxxxxxx>
Signed-off-by: Donet Tom <donettom@xxxxxxxxxxxxx>
Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
Cc: Ben Widawsky <ben.widawsky@xxxxxxxxx>
Cc: Dan Williams <dan.j.williams@xxxxxxxxx>
Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
Cc: Feng Tang <feng.tang@xxxxxxxxx>
Cc: "Huang, Ying" <ying.huang@xxxxxxxxx>
Cc: Hugh Dickins <hughd@xxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
Cc: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
Cc: Mel Gorman <mgorman@xxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxxxx>
Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
Cc: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
Cc: Rik van Riel <riel@xxxxxxxxxxx>
Cc: Suren Baghdasaryan <surenb@xxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/mempolicy.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
--- a/mm/mempolicy.c~mm-numa_balancing-allow-migrate-on-protnone-reference-with-mpol_preferred_many-policy
+++ a/mm/mempolicy.c
@@ -1503,9 +1503,10 @@ static inline int sanitize_mpol_flags(in
if ((*flags & MPOL_F_STATIC_NODES) && (*flags & MPOL_F_RELATIVE_NODES))
return -EINVAL;
if (*flags & MPOL_F_NUMA_BALANCING) {
- if (*mode != MPOL_BIND)
+ if (*mode == MPOL_BIND || *mode == MPOL_PREFERRED_MANY)
+ *flags |= (MPOL_F_MOF | MPOL_F_MORON);
+ else
return -EINVAL;
- *flags |= (MPOL_F_MOF | MPOL_F_MORON);
}
return 0;
}
@@ -2713,6 +2714,23 @@ static void sp_free(struct sp_node *n)
kmem_cache_free(sn_cache, n);
}
+static inline bool mpol_preferred_should_numa_migrate(int exec_node, int folio_node,
+ struct mempolicy *pol)
+{
+ /* if the executing node is in the policy node mask, migrate */
+ if (node_isset(exec_node, pol->nodes))
+ return true;
+
+ /* If the folio node is in policy node mask, don't migrate */
+ if (node_isset(folio_node, pol->nodes))
+ return false;
+ /*
+ * both the folio node and executing node are outside the policy nodemask,
+ * migrate as normal numa fault migration.
+ */
+ return true;
+}
+
/**
* mpol_misplaced - check whether current folio node is valid in policy
*
@@ -2780,6 +2798,12 @@ int mpol_misplaced(struct folio *folio,
break;
case MPOL_PREFERRED_MANY:
+ if (pol->flags & MPOL_F_MORON) {
+ if (!mpol_preferred_should_numa_migrate(thisnid, curnid, pol))
+ goto out;
+ break;
+ }
+
/*
* use current page if in policy nodemask,
* else select nearest allowed node, if any.
_
Patches currently in -mm which might be from donettom@xxxxxxxxxxxxx are
