The current implementation to identify the demotion
targets limits some of the opportunities to share
the demotion targets between multiple source nodes.
Implement a logic to identify the loop in the demotion
targets such that all the possibilities of demotion can
be utilized. Don't share the used targets between all
the nodes, instead create the used targets from scratch
for each individual node based on for what all node this
node is a demotion target. This helps to share the demotion
targets without missing any possible way of demotion.
e.g. with below NUMA topology, where node 0 & 1 are
cpu + dram nodes, node 2 & 3 are equally slower memory
only nodes, and node 4 is slowest memory only node,
available: 5 nodes (0-4)
node 0 cpus: 0 1
node 0 size: n MB
node 0 free: n MB
node 1 cpus: 2 3
node 1 size: n MB
node 1 free: n MB
node 2 cpus:
node 2 size: n MB
node 2 free: n MB
node 3 cpus:
node 3 size: n MB
node 3 free: n MB
node 4 cpus:
node 4 size: n MB
node 4 free: n MB
node distances:
node 0 1 2 3 4
0: 10 20 40 40 80
1: 20 10 40 40 80
2: 40 40 10 40 80
3: 40 40 40 10 80
4: 80 80 80 80 10
The existing implementation gives below demotion targets,
node demotion_target
0 3, 2
1 4
2 X
3 X
4 X
With this patch applied, below are the demotion targets,
node demotion_target
0 3, 2
1 3, 2
2 3
3 4
4 X
e.g. with below NUMA topology, where node 0, 1 & 2 are
cpu + dram nodes and node 3 is slow memory node,
available: 4 nodes (0-3)
node 0 cpus: 0 1
node 0 size: n MB
node 0 free: n MB
node 1 cpus: 2 3
node 1 size: n MB
node 1 free: n MB
node 2 cpus: 4 5
node 2 size: n MB
node 2 free: n MB
node 3 cpus:
node 3 size: n MB
node 3 free: n MB
node distances:
node 0 1 2 3
0: 10 20 20 40
1: 20 10 20 40
2: 20 20 10 40
3: 40 40 40 10
The existing implementation gives below demotion targets,
node demotion_target
0 3
1 X
2 X
3 X
With this patch applied, below are the demotion targets,
node demotion_target
0 3
1 3
2 3
3 X
with below NUMA topology, where node 0 & 2 are cpu + dram
nodes and node 1 & 3 are slow memory nodes,
available: 4 nodes (0-3)
node 0 cpus: 0 1
node 0 size: n MB
node 0 free: n MB
node 1 cpus:
node 1 size: n MB
node 1 free: n MB
node 2 cpus: 2 3
node 2 size: n MB
node 2 free: n MB
node 3 cpus:
node 3 size: n MB
node 3 free: n MB
node distances:
node 0 1 2 3
0: 10 40 20 80
1: 40 10 80 80
2: 20 80 10 40
3: 80 80 40 10
The existing implementation gives below demotion targets,
node demotion_target
0 3
1 X
2 3
3 X
With this patch applied, below are the demotion targets,
node demotion_target
0 1
1 3
2 3
3 X
As it can be seen above, node 3 can be demotion target for node
1 but existing implementation doesn't configure it that way. It
is better to move pages from node 1 to node 3 instead of moving
it from node 1 to swap.
Signed-off-by: Jagdish Gediya <[email protected]>
Signed-off-by: Aneesh Kumar K.V <[email protected]>
---
mm/migrate.c | 75 ++++++++++++++++++++++++++++------------------------
1 file changed, 41 insertions(+), 34 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 3d60823afd2d..7ec8d934e706 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2381,10 +2381,13 @@ static int establish_migrate_target(int node, nodemask_t *used,
*/
static void __set_migration_target_nodes(void)
{
- nodemask_t next_pass = NODE_MASK_NONE;
- nodemask_t this_pass = NODE_MASK_NONE;
nodemask_t used_targets = NODE_MASK_NONE;
int node, best_distance;
+ nodemask_t *src_nodes;
+
+ src_nodes = kcalloc(nr_node_ids, sizeof(nodemask_t), GFP_KERNEL);
+ if (!src_nodes)
+ return;
/*
* Avoid any oddities like cycles that could occur
@@ -2393,29 +2396,39 @@ static void __set_migration_target_nodes(void)
*/
disable_all_migrate_targets();
- /*
- * Allocations go close to CPUs, first. Assume that
- * the migration path starts at the nodes with CPUs.
- */
- next_pass = node_states[N_CPU];
-again:
- this_pass = next_pass;
- next_pass = NODE_MASK_NONE;
- /*
- * To avoid cycles in the migration "graph", ensure
- * that migration sources are not future targets by
- * setting them in 'used_targets'. Do this only
- * once per pass so that multiple source nodes can
- * share a target node.
- *
- * 'used_targets' will become unavailable in future
- * passes. This limits some opportunities for
- * multiple source nodes to share a destination.
- */
- nodes_or(used_targets, used_targets, this_pass);
+ for_each_online_node(node) {
+ int tmp_node;
- for_each_node_mask(node, this_pass) {
best_distance = -1;
+ used_targets = NODE_MASK_NONE;
+
+ /*
+ * Avoid adding same node as the demotion target.
+ */
+ node_set(node, used_targets);
+
+ /*
+ * Add CPU NUMA nodes to the used target list so that it
+ * won't be considered a demotion target.
+ */
+ nodes_or(used_targets, used_targets, node_states[N_CPU]);
+
+ /*
+ * Add all nodes that has appeared as source node of demotion
+ * for this target node.
+ *
+ * To avoid cycles in the migration "graph", ensure
+ * that migration sources are not future targets by
+ * setting them in 'used_targets'.
+ */
+ for_each_node_mask(tmp_node, src_nodes[node])
+ nodes_or(used_targets, used_targets, src_nodes[tmp_node]);
+
+ /*
+ * Now update the demotion src nodes with other nodes in graph
+ * which got computed above.
+ */
+ nodes_or(src_nodes[node], src_nodes[node], used_targets);
/*
* Try to set up the migration path for the node, and the target
@@ -2434,20 +2447,14 @@ static void __set_migration_target_nodes(void)
best_distance = node_distance(node, target_node);
/*
- * Visit targets from this pass in the next pass.
- * Eventually, every node will have been part of
- * a pass, and will become set in 'used_targets'.
+ * Add this node in the src_nodes list so that we can
+ * detect the looping.
*/
- node_set(target_node, next_pass);
+ node_set(node, src_nodes[target_node]);
} while (1);
}
- /*
- * 'next_pass' contains nodes which became migration
- * targets in this pass. Make additional passes until
- * no more migrations targets are available.
- */
- if (!nodes_empty(next_pass))
- goto again;
+
+ kfree(src_nodes);
}
/*
--
2.35.1
On 3/29/22 04:52, Jagdish Gediya wrote:
> The current implementation to identify the demotion
> targets limits some of the opportunities to share
> the demotion targets between multiple source nodes.
This changelog is a bit unsatisfying. It basically says: the current
code isn't working, throw some more code at the problem.
I'd love to see some more information about *why* the current code
doesn't work. Is it purely a bug or was it mis-designed?
I actually wrote it intending for it to handle cases like you describe
while not leaving lots of nodes without demotion targets.
On Tue, Mar 29, 2022 at 07:31:12AM -0700, Dave Hansen wrote:
> On 3/29/22 04:52, Jagdish Gediya wrote:
> > The current implementation to identify the demotion
> > targets limits some of the opportunities to share
> > the demotion targets between multiple source nodes.
>
> This changelog is a bit unsatisfying. It basically says: the current
> code isn't working, throw some more code at the problem.
The current code works but it doesn't utilize all the possibilities
for the demotion. One of the comment in the current code says that
'used_targets will become unavailable in future passes. This limits
some opportunities for multiple source nodes to share a destination.'
This patch removes those limitation. The current limitation is single
used_target nodemask sharing between all the nodes, This patch prepares
the used_targets from scratch for each individual node and then tries
to avoid the looping based on what demotion targets are not possible
for that particular node based on the data we accumulate in newly
defined src_nodes array.
For example, with below numa topology where node 0,1 & 2 are cpu + dram
node and node 3 is slow memory node,
node 0 1 2 3
0: 10 20 20 40
1: 20 10 20 40
2: 20 20 10 40
3: 40 40 40 10
once node 3 is utilized for node 0, it can not be shared for node 1 & 2
because in current code, used_targets will have that set even when we
find demotion targets for 1 & 2.
> I'd love to see some more information about *why* the current code
> doesn't work. Is it purely a bug or was it mis-designed?
I think the design seems to be intended because as per the comment
in the current code, it was known that there are limits to the node
sharing as a demotion target.
> I actually wrote it intending for it to handle cases like you describe
> while not leaving lots of nodes without demotion targets.
if you see the examples I have given in the commit message, the current
code misses many opportunities for the demotion, so current
implementation to avoid the looping is not the best as I have explained
above, that is where this patch is required.
Baolin Wang <[email protected]> writes:
> On 3/29/2022 10:04 PM, Jagdish Gediya wrote:
>> On Tue, Mar 29, 2022 at 08:26:05PM +0800, Baolin Wang wrote:
>> Hi Baolin,
>>> Hi Jagdish,
>>>
>>> On 3/29/2022 7:52 PM, Jagdish Gediya wrote:
>>>> The current implementation to identify the demotion
>>>> targets limits some of the opportunities to share
>>>> the demotion targets between multiple source nodes.
>>>>
>>>> Implement a logic to identify the loop in the demotion
>>>> targets such that all the possibilities of demotion can
>>>> be utilized. Don't share the used targets between all
>>>> the nodes, instead create the used targets from scratch
>>>> for each individual node based on for what all node this
>>>> node is a demotion target. This helps to share the demotion
>>>> targets without missing any possible way of demotion.
>>>>
>>>> e.g. with below NUMA topology, where node 0 & 1 are
>>>> cpu + dram nodes, node 2 & 3 are equally slower memory
>>>> only nodes, and node 4 is slowest memory only node,
>>>>
>>>> available: 5 nodes (0-4)
>>>> node 0 cpus: 0 1
>>>> node 0 size: n MB
>>>> node 0 free: n MB
>>>> node 1 cpus: 2 3
>>>> node 1 size: n MB
>>>> node 1 free: n MB
>>>> node 2 cpus:
>>>> node 2 size: n MB
>>>> node 2 free: n MB
>>>> node 3 cpus:
>>>> node 3 size: n MB
>>>> node 3 free: n MB
>>>> node 4 cpus:
>>>> node 4 size: n MB
>>>> node 4 free: n MB
>>>> node distances:
>>>> node 0 1 2 3 4
>>>> 0: 10 20 40 40 80
>>>> 1: 20 10 40 40 80
>>>> 2: 40 40 10 40 80
>>>> 3: 40 40 40 10 80
>>>> 4: 80 80 80 80 10
>>>>
>>>> The existing implementation gives below demotion targets,
>>>>
>>>> node demotion_target
>>>> 0 3, 2
>>>> 1 4
>>>> 2 X
>>>> 3 X
>>>> 4 X
>>>>
>>>> With this patch applied, below are the demotion targets,
>>>>
>>>> node demotion_target
>>>> 0 3, 2
>>>> 1 3, 2
>>>> 2 3
>>>> 3 4
>>>> 4 X
>>>
>>> Node 2 and node 3 both are slow memory and have same distance, why node 2
>>> should demote cold memory to node 3? They should have the same target
>>> demotion node 4, which is the slowest memory node, right?
>>>
>> Current demotion target finding algorithm works based on best distance, as distance between node 2 & 3 is 40 and distance between node 2 & 4 is 80, node 2 demotes to node 3.
>
> If node 2 can demote to node 3, which means node 3's memory is colder
> than node 2, right? The accessing time of node 3 should be larger than
> node 2, then we can demote colder memory to node 3 from node 2.
>
> But node 2 and node 3 are same memory type and have same distance, the
> accessing time of node 2 and node 3 should be same too, so why add so
> many page migration between node 2 and node 3? I'm still not sure the
> benefits.
>
> Huang Ying and Dave, how do you think about this demotion targets?
Yes. I think the demotion target of 2 should be 4, as in my another
email in this thread. Demoting from 2 to 3 makes no sense.
Best Regards,
Huang, Ying
[snip]
Hi, Jagdish,
Jagdish Gediya <[email protected]> writes:
> The current implementation to identify the demotion
> targets limits some of the opportunities to share
> the demotion targets between multiple source nodes.
Yes. It sounds reasonable to share demotion targets among multiple
source nodes.
One question, are example machines below are real hardware now or in
near future? Or you just think they are possible?
And, before going into the implementation details, I think that we can
discuss the perfect demotion order firstly.
> Implement a logic to identify the loop in the demotion
> targets such that all the possibilities of demotion can
> be utilized. Don't share the used targets between all
> the nodes, instead create the used targets from scratch
> for each individual node based on for what all node this
> node is a demotion target. This helps to share the demotion
> targets without missing any possible way of demotion.
>
> e.g. with below NUMA topology, where node 0 & 1 are
> cpu + dram nodes, node 2 & 3 are equally slower memory
> only nodes, and node 4 is slowest memory only node,
>
> available: 5 nodes (0-4)
> node 0 cpus: 0 1
> node 0 size: n MB
> node 0 free: n MB
> node 1 cpus: 2 3
> node 1 size: n MB
> node 1 free: n MB
> node 2 cpus:
> node 2 size: n MB
> node 2 free: n MB
> node 3 cpus:
> node 3 size: n MB
> node 3 free: n MB
> node 4 cpus:
> node 4 size: n MB
> node 4 free: n MB
> node distances:
> node 0 1 2 3 4
> 0: 10 20 40 40 80
> 1: 20 10 40 40 80
> 2: 40 40 10 40 80
> 3: 40 40 40 10 80
> 4: 80 80 80 80 10
>
> The existing implementation gives below demotion targets,
>
> node demotion_target
> 0 3, 2
> 1 4
> 2 X
> 3 X
> 4 X
>
> With this patch applied, below are the demotion targets,
>
> node demotion_target
> 0 3, 2
> 1 3, 2
> 2 3
> 3 4
> 4 X
For such machine, I think the perfect demotion order is,
node demotion_target
0 2, 3
1 2, 3
2 4
3 4
4 X
> e.g. with below NUMA topology, where node 0, 1 & 2 are
> cpu + dram nodes and node 3 is slow memory node,
>
> available: 4 nodes (0-3)
> node 0 cpus: 0 1
> node 0 size: n MB
> node 0 free: n MB
> node 1 cpus: 2 3
> node 1 size: n MB
> node 1 free: n MB
> node 2 cpus: 4 5
> node 2 size: n MB
> node 2 free: n MB
> node 3 cpus:
> node 3 size: n MB
> node 3 free: n MB
> node distances:
> node 0 1 2 3
> 0: 10 20 20 40
> 1: 20 10 20 40
> 2: 20 20 10 40
> 3: 40 40 40 10
>
> The existing implementation gives below demotion targets,
>
> node demotion_target
> 0 3
> 1 X
> 2 X
> 3 X
>
> With this patch applied, below are the demotion targets,
>
> node demotion_target
> 0 3
> 1 3
> 2 3
> 3 X
I think this is perfect already.
> with below NUMA topology, where node 0 & 2 are cpu + dram
> nodes and node 1 & 3 are slow memory nodes,
>
> available: 4 nodes (0-3)
> node 0 cpus: 0 1
> node 0 size: n MB
> node 0 free: n MB
> node 1 cpus:
> node 1 size: n MB
> node 1 free: n MB
> node 2 cpus: 2 3
> node 2 size: n MB
> node 2 free: n MB
> node 3 cpus:
> node 3 size: n MB
> node 3 free: n MB
> node distances:
> node 0 1 2 3
> 0: 10 40 20 80
> 1: 40 10 80 80
> 2: 20 80 10 40
> 3: 80 80 40 10
>
> The existing implementation gives below demotion targets,
>
> node demotion_target
> 0 3
> 1 X
> 2 3
> 3 X
Should be as below as you said in another email of the thread.
node demotion_target
0 1
1 X
2 3
3 X
> With this patch applied, below are the demotion targets,
>
> node demotion_target
> 0 1
> 1 3
> 2 3
> 3 X
The original demotion order looks better for me. 1 and 3 are at the
same level from the perspective of the whole system.
Another example, node 0 & 2 are cpu + dram nodes and node 1 are slow
memory node near node 0,
available: 3 nodes (0-2)
node 0 cpus: 0 1
node 0 size: n MB
node 0 free: n MB
node 1 cpus:
node 1 size: n MB
node 1 free: n MB
node 2 cpus: 2 3
node 2 size: n MB
node 2 free: n MB
node distances:
node 0 1 2
0: 10 40 20
1: 40 10 80
2: 20 80 10
Demotion order 1:
node demotion_target
0 1
1 X
2 X
Demotion order 2:
node demotion_target
0 1
1 X
2 1
Demotion order 2 looks better. But I think that demotion order 1 makes
some sense too (like node reclaim mode).
It seems that,
If a demotion target has same distance to several current demotion
sources, the demotion target should be shared among the demotion
sources.
And as Dave pointed out, we may eventually need a mechanism to override
the default demotion order generated automatically. So we can just use
some simple mechanism that makes sense in most cases in kernel
automatically. And leave the best demotion for users to some
customization mechanism.
> As it can be seen above, node 3 can be demotion target for node
> 1 but existing implementation doesn't configure it that way. It
> is better to move pages from node 1 to node 3 instead of moving
> it from node 1 to swap.
>
> Signed-off-by: Jagdish Gediya <[email protected]>
> Signed-off-by: Aneesh Kumar K.V <[email protected]>
Best Regards,
Huang, Ying
[snip]
On 3/29/22 09:46, Jagdish Gediya wrote:
>> I'd love to see some more information about *why* the current code
>> doesn't work. Is it purely a bug or was it mis-designed?
> I think the design seems to be intended because as per the comment
> in the current code, it was known that there are limits to the node
> sharing as a demotion target.
Ahh, that makes sense.
You've got some slow memory that's not really associated closely enough
with an initiator node to be used exclusively for demotions from that
node. The original code was really intended for demotions when the
system is made up of relatively identical building blocks, like one CPU
with two kinds of memory attached.
I think what you're doing here makes sense. The only thing I'll say is
that, at some point, we need to stop messing with the demotion order
that the kernel comes up with. It's not going to be able to handle
*everything* perfectly. We're probably not at the point that we should
stop enhancing the kernel-generated demotion order, but let's at least
keep in mind that we should stop eventually.
"Aneesh Kumar K.V" <[email protected]> writes:
> "Huang, Ying" <[email protected]> writes:
>
>> Hi, Jagdish,
>>
>> Jagdish Gediya <[email protected]> writes:
>>
>
> ...
>
>>> e.g. with below NUMA topology, where node 0 & 1 are
>>> cpu + dram nodes, node 2 & 3 are equally slower memory
>>> only nodes, and node 4 is slowest memory only node,
>>>
>>> available: 5 nodes (0-4)
>>> node 0 cpus: 0 1
>>> node 0 size: n MB
>>> node 0 free: n MB
>>> node 1 cpus: 2 3
>>> node 1 size: n MB
>>> node 1 free: n MB
>>> node 2 cpus:
>>> node 2 size: n MB
>>> node 2 free: n MB
>>> node 3 cpus:
>>> node 3 size: n MB
>>> node 3 free: n MB
>>> node 4 cpus:
>>> node 4 size: n MB
>>> node 4 free: n MB
>>> node distances:
>>> node 0 1 2 3 4
>>> 0: 10 20 40 40 80
>>> 1: 20 10 40 40 80
>>> 2: 40 40 10 40 80
>>> 3: 40 40 40 10 80
>>> 4: 80 80 80 80 10
>>>
>>> The existing implementation gives below demotion targets,
>>>
>>> node demotion_target
>>> 0 3, 2
>>> 1 4
>>> 2 X
>>> 3 X
>>> 4 X
>>>
>>> With this patch applied, below are the demotion targets,
>>>
>>> node demotion_target
>>> 0 3, 2
>>> 1 3, 2
>>> 2 3
>>> 3 4
>>> 4 X
>>
>> For such machine, I think the perfect demotion order is,
>>
>> node demotion_target
>> 0 2, 3
>> 1 2, 3
>> 2 4
>> 3 4
>> 4 X
>
> I guess the "equally slow nodes" is a confusing definition here. Now if the
> system consists of 2 1GB equally slow memory and the firmware doesn't want to
> differentiate between them, firmware can present a single NUMA node
> with 2GB capacity? The fact that we are finding two NUMA nodes is a hint
> that there is some difference between these two memory devices. This is
> also captured by the fact that the distance between 2 and 3 is 40 and not 10.
Do you have more information about this?
Best Regards,
Huang, Ying
> For that specific topology where the distance between 2 and 3 is 40 and 2
> and 4 is 80, the demotion target derived by the new code is better
> right?
>
> ...
>
>
> -aneesh
Hi Huang,
On Wed, Mar 30, 2022 at 02:46:51PM +0800, Huang, Ying wrote:
> Hi, Jagdish,
>
> Jagdish Gediya <[email protected]> writes:
>
> > The current implementation to identify the demotion
> > targets limits some of the opportunities to share
> > the demotion targets between multiple source nodes.
>
> Yes. It sounds reasonable to share demotion targets among multiple
> source nodes.
>
> One question, are example machines below are real hardware now or in
> near future? Or you just think they are possible?
They are not real hardware right now, they are the future possibilities.
> And, before going into the implementation details, I think that we can
> discuss the perfect demotion order firstly.
>
> > Implement a logic to identify the loop in the demotion
> > targets such that all the possibilities of demotion can
> > be utilized. Don't share the used targets between all
> > the nodes, instead create the used targets from scratch
> > for each individual node based on for what all node this
> > node is a demotion target. This helps to share the demotion
> > targets without missing any possible way of demotion.
> >
> > e.g. with below NUMA topology, where node 0 & 1 are
> > cpu + dram nodes, node 2 & 3 are equally slower memory
> > only nodes, and node 4 is slowest memory only node,
> >
> > available: 5 nodes (0-4)
> > node 0 cpus: 0 1
> > node 0 size: n MB
> > node 0 free: n MB
> > node 1 cpus: 2 3
> > node 1 size: n MB
> > node 1 free: n MB
> > node 2 cpus:
> > node 2 size: n MB
> > node 2 free: n MB
> > node 3 cpus:
> > node 3 size: n MB
> > node 3 free: n MB
> > node 4 cpus:
> > node 4 size: n MB
> > node 4 free: n MB
> > node distances:
> > node 0 1 2 3 4
> > 0: 10 20 40 40 80
> > 1: 20 10 40 40 80
> > 2: 40 40 10 40 80
> > 3: 40 40 40 10 80
> > 4: 80 80 80 80 10
> >
> > The existing implementation gives below demotion targets,
> >
> > node demotion_target
> > 0 3, 2
> > 1 4
> > 2 X
> > 3 X
> > 4 X
> >
> > With this patch applied, below are the demotion targets,
> >
> > node demotion_target
> > 0 3, 2
> > 1 3, 2
> > 2 3
> > 3 4
> > 4 X
>
> For such machine, I think the perfect demotion order is,
>
> node demotion_target
> 0 2, 3
> 1 2, 3
> 2 4
> 3 4
> 4 X
Current implementation works based on the best distance algorithm,
this patch doesn't change it either, so based on the distance, the
demotion list is what I have mentioned. I understand 4 is better
target for 2 but as per the mentioned numa distances and current
algorithm, it doesn't get configured like that in the kernel.
> > e.g. with below NUMA topology, where node 0, 1 & 2 are
> > cpu + dram nodes and node 3 is slow memory node,
> >
> > available: 4 nodes (0-3)
> > node 0 cpus: 0 1
> > node 0 size: n MB
> > node 0 free: n MB
> > node 1 cpus: 2 3
> > node 1 size: n MB
> > node 1 free: n MB
> > node 2 cpus: 4 5
> > node 2 size: n MB
> > node 2 free: n MB
> > node 3 cpus:
> > node 3 size: n MB
> > node 3 free: n MB
> > node distances:
> > node 0 1 2 3
> > 0: 10 20 20 40
> > 1: 20 10 20 40
> > 2: 20 20 10 40
> > 3: 40 40 40 10
> >
> > The existing implementation gives below demotion targets,
> >
> > node demotion_target
> > 0 3
> > 1 X
> > 2 X
> > 3 X
> >
> > With this patch applied, below are the demotion targets,
> >
> > node demotion_target
> > 0 3
> > 1 3
> > 2 3
> > 3 X
>
> I think this is perfect already.
>
> > with below NUMA topology, where node 0 & 2 are cpu + dram
> > nodes and node 1 & 3 are slow memory nodes,
> >
> > available: 4 nodes (0-3)
> > node 0 cpus: 0 1
> > node 0 size: n MB
> > node 0 free: n MB
> > node 1 cpus:
> > node 1 size: n MB
> > node 1 free: n MB
> > node 2 cpus: 2 3
> > node 2 size: n MB
> > node 2 free: n MB
> > node 3 cpus:
> > node 3 size: n MB
> > node 3 free: n MB
> > node distances:
> > node 0 1 2 3
> > 0: 10 40 20 80
> > 1: 40 10 80 80
> > 2: 20 80 10 40
> > 3: 80 80 40 10
> >
> > The existing implementation gives below demotion targets,
> >
> > node demotion_target
> > 0 3
> > 1 X
> > 2 3
> > 3 X
>
> Should be as below as you said in another email of the thread.
>
> node demotion_target
> 0 1
> 1 X
> 2 3
> 3 X
>
> > With this patch applied, below are the demotion targets,
> >
> > node demotion_target
> > 0 1
> > 1 3
> > 2 3
> > 3 X
>
> The original demotion order looks better for me. 1 and 3 are at the
> same level from the perspective of the whole system.
>
> Another example, node 0 & 2 are cpu + dram nodes and node 1 are slow
> memory node near node 0,
>
> available: 3 nodes (0-2)
> node 0 cpus: 0 1
> node 0 size: n MB
> node 0 free: n MB
> node 1 cpus:
> node 1 size: n MB
> node 1 free: n MB
> node 2 cpus: 2 3
> node 2 size: n MB
> node 2 free: n MB
> node distances:
> node 0 1 2
> 0: 10 40 20
> 1: 40 10 80
> 2: 20 80 10
>
>
> Demotion order 1:
>
> node demotion_target
> 0 1
> 1 X
> 2 X
>
> Demotion order 2:
>
> node demotion_target
> 0 1
> 1 X
> 2 1
>
> Demotion order 2 looks better. But I think that demotion order 1 makes
> some sense too (like node reclaim mode).
>
> It seems that,
>
> If a demotion target has same distance to several current demotion
> sources, the demotion target should be shared among the demotion
> sources.
Yes, and that is where this patch is useful.
> And as Dave pointed out, we may eventually need a mechanism to override
> the default demotion order generated automatically. So we can just use
> some simple mechanism that makes sense in most cases in kernel
> automatically. And leave the best demotion for users to some
> customization mechanism.
Yes, We need a mechanism to override the default demotion list prepared
by the current implementation. PowerVM can have a cpu less dram node
as well, which infact are not the right target for demotion because
it is the fast memory. We need to distinguish between memory tiers
so that slow memory can be utilized for the demotion even when there
are fast memory only numa nodes.
I think we may see implementations in future to override the default
behavior e.g. when systems have both fast only and slow only memory
nodes and in that case it will make sense to demote to slow memory
only node even if it is far, but this patch is to put the current
implementation to its intended design 'best distance based demotion
targets'.
> > As it can be seen above, node 3 can be demotion target for node
> > 1 but existing implementation doesn't configure it that way. It
> > is better to move pages from node 1 to node 3 instead of moving
> > it from node 1 to swap.
> >
> > Signed-off-by: Jagdish Gediya <[email protected]>
> > Signed-off-by: Aneesh Kumar K.V <[email protected]>
>
> Best Regards,
> Huang, Ying
>
> [snip]
>
Best Regards,
Jagdish
"Huang, Ying" <[email protected]> writes:
> Hi, Jagdish,
>
> Jagdish Gediya <[email protected]> writes:
>
...
>> e.g. with below NUMA topology, where node 0 & 1 are
>> cpu + dram nodes, node 2 & 3 are equally slower memory
>> only nodes, and node 4 is slowest memory only node,
>>
>> available: 5 nodes (0-4)
>> node 0 cpus: 0 1
>> node 0 size: n MB
>> node 0 free: n MB
>> node 1 cpus: 2 3
>> node 1 size: n MB
>> node 1 free: n MB
>> node 2 cpus:
>> node 2 size: n MB
>> node 2 free: n MB
>> node 3 cpus:
>> node 3 size: n MB
>> node 3 free: n MB
>> node 4 cpus:
>> node 4 size: n MB
>> node 4 free: n MB
>> node distances:
>> node 0 1 2 3 4
>> 0: 10 20 40 40 80
>> 1: 20 10 40 40 80
>> 2: 40 40 10 40 80
>> 3: 40 40 40 10 80
>> 4: 80 80 80 80 10
>>
>> The existing implementation gives below demotion targets,
>>
>> node demotion_target
>> 0 3, 2
>> 1 4
>> 2 X
>> 3 X
>> 4 X
>>
>> With this patch applied, below are the demotion targets,
>>
>> node demotion_target
>> 0 3, 2
>> 1 3, 2
>> 2 3
>> 3 4
>> 4 X
>
> For such machine, I think the perfect demotion order is,
>
> node demotion_target
> 0 2, 3
> 1 2, 3
> 2 4
> 3 4
> 4 X
I guess the "equally slow nodes" is a confusing definition here. Now if the
system consists of 2 1GB equally slow memory and the firmware doesn't want to
differentiate between them, firmware can present a single NUMA node
with 2GB capacity? The fact that we are finding two NUMA nodes is a hint
that there is some difference between these two memory devices. This is
also captured by the fact that the distance between 2 and 3 is 40 and not 10.
For that specific topology where the distance between 2 and 3 is 40 and 2
and 4 is 80, the demotion target derived by the new code is better
right?
...
-aneesh
Jagdish Gediya <[email protected]> writes:
> Hi Huang,
>
> On Wed, Mar 30, 2022 at 02:46:51PM +0800, Huang, Ying wrote:
>> Hi, Jagdish,
>>
>> Jagdish Gediya <[email protected]> writes:
>>
>> > The current implementation to identify the demotion
>> > targets limits some of the opportunities to share
>> > the demotion targets between multiple source nodes.
>>
>> Yes. It sounds reasonable to share demotion targets among multiple
>> source nodes.
>>
>> One question, are example machines below are real hardware now or in
>> near future? Or you just think they are possible?
>
> They are not real hardware right now, they are the future possibilities.
>
>> And, before going into the implementation details, I think that we can
>> discuss the perfect demotion order firstly.
>>
>> > Implement a logic to identify the loop in the demotion
>> > targets such that all the possibilities of demotion can
>> > be utilized. Don't share the used targets between all
>> > the nodes, instead create the used targets from scratch
>> > for each individual node based on for what all node this
>> > node is a demotion target. This helps to share the demotion
>> > targets without missing any possible way of demotion.
>> >
>> > e.g. with below NUMA topology, where node 0 & 1 are
>> > cpu + dram nodes, node 2 & 3 are equally slower memory
>> > only nodes, and node 4 is slowest memory only node,
>> >
>> > available: 5 nodes (0-4)
>> > node 0 cpus: 0 1
>> > node 0 size: n MB
>> > node 0 free: n MB
>> > node 1 cpus: 2 3
>> > node 1 size: n MB
>> > node 1 free: n MB
>> > node 2 cpus:
>> > node 2 size: n MB
>> > node 2 free: n MB
>> > node 3 cpus:
>> > node 3 size: n MB
>> > node 3 free: n MB
>> > node 4 cpus:
>> > node 4 size: n MB
>> > node 4 free: n MB
>> > node distances:
>> > node 0 1 2 3 4
>> > 0: 10 20 40 40 80
>> > 1: 20 10 40 40 80
>> > 2: 40 40 10 40 80
>> > 3: 40 40 40 10 80
>> > 4: 80 80 80 80 10
>> >
>> > The existing implementation gives below demotion targets,
>> >
>> > node demotion_target
>> > 0 3, 2
>> > 1 4
>> > 2 X
>> > 3 X
>> > 4 X
>> >
>> > With this patch applied, below are the demotion targets,
>> >
>> > node demotion_target
>> > 0 3, 2
>> > 1 3, 2
>> > 2 3
>> > 3 4
>> > 4 X
>>
>> For such machine, I think the perfect demotion order is,
>>
>> node demotion_target
>> 0 2, 3
>> 1 2, 3
>> 2 4
>> 3 4
>> 4 X
>
> Current implementation works based on the best distance algorithm,
> this patch doesn't change it either, so based on the distance, the
> demotion list is what I have mentioned. I understand 4 is better
> target for 2 but as per the mentioned numa distances and current
> algorithm, it doesn't get configured like that in the kernel.
If we agree on the perfect demotion order, can we revise the current
algorithm a little to make it happen?
Is the following solution possible?
1st round:
sources: 0, 1
exclude targets: 0, 1
result: 0 - > 2,3; 1 -> 2,3
2nd round:
sources: 2, 3
exclude targets: 0, 1, 2, 3
result: 2 -> 4; 3 -> 4
3rd round:
sources: 4
exclude targets: 0, 1, 2, 3, 4
result: 4 -> X
That is, in each round, we exclude the sources and targets in the
previous rounds as demotion targets. Compared with the original
algorithm, we don't exclude targets used in the current round,
but we will exclude them in the next round.
If this doesn't work, can you think about whether it is possible to find
some way?
>> > e.g. with below NUMA topology, where node 0, 1 & 2 are
>> > cpu + dram nodes and node 3 is slow memory node,
>> >
>> > available: 4 nodes (0-3)
>> > node 0 cpus: 0 1
>> > node 0 size: n MB
>> > node 0 free: n MB
>> > node 1 cpus: 2 3
>> > node 1 size: n MB
>> > node 1 free: n MB
>> > node 2 cpus: 4 5
>> > node 2 size: n MB
>> > node 2 free: n MB
>> > node 3 cpus:
>> > node 3 size: n MB
>> > node 3 free: n MB
>> > node distances:
>> > node 0 1 2 3
>> > 0: 10 20 20 40
>> > 1: 20 10 20 40
>> > 2: 20 20 10 40
>> > 3: 40 40 40 10
>> >
>> > The existing implementation gives below demotion targets,
>> >
>> > node demotion_target
>> > 0 3
>> > 1 X
>> > 2 X
>> > 3 X
>> >
>> > With this patch applied, below are the demotion targets,
>> >
>> > node demotion_target
>> > 0 3
>> > 1 3
>> > 2 3
>> > 3 X
>>
>> I think this is perfect already.
>>
>> > with below NUMA topology, where node 0 & 2 are cpu + dram
>> > nodes and node 1 & 3 are slow memory nodes,
>> >
>> > available: 4 nodes (0-3)
>> > node 0 cpus: 0 1
>> > node 0 size: n MB
>> > node 0 free: n MB
>> > node 1 cpus:
>> > node 1 size: n MB
>> > node 1 free: n MB
>> > node 2 cpus: 2 3
>> > node 2 size: n MB
>> > node 2 free: n MB
>> > node 3 cpus:
>> > node 3 size: n MB
>> > node 3 free: n MB
>> > node distances:
>> > node 0 1 2 3
>> > 0: 10 40 20 80
>> > 1: 40 10 80 80
>> > 2: 20 80 10 40
>> > 3: 80 80 40 10
>> >
>> > The existing implementation gives below demotion targets,
>> >
>> > node demotion_target
>> > 0 3
>> > 1 X
>> > 2 3
>> > 3 X
>>
>> Should be as below as you said in another email of the thread.
>>
>> node demotion_target
>> 0 1
>> 1 X
>> 2 3
>> 3 X
>>
>> > With this patch applied, below are the demotion targets,
>> >
>> > node demotion_target
>> > 0 1
>> > 1 3
>> > 2 3
>> > 3 X
>>
>> The original demotion order looks better for me. 1 and 3 are at the
>> same level from the perspective of the whole system.
>>
>> Another example, node 0 & 2 are cpu + dram nodes and node 1 are slow
>> memory node near node 0,
>>
>> available: 3 nodes (0-2)
>> node 0 cpus: 0 1
>> node 0 size: n MB
>> node 0 free: n MB
>> node 1 cpus:
>> node 1 size: n MB
>> node 1 free: n MB
>> node 2 cpus: 2 3
>> node 2 size: n MB
>> node 2 free: n MB
>> node distances:
>> node 0 1 2
>> 0: 10 40 20
>> 1: 40 10 80
>> 2: 20 80 10
>>
>>
>> Demotion order 1:
>>
>> node demotion_target
>> 0 1
>> 1 X
>> 2 X
>>
>> Demotion order 2:
>>
>> node demotion_target
>> 0 1
>> 1 X
>> 2 1
>>
>> Demotion order 2 looks better. But I think that demotion order 1 makes
>> some sense too (like node reclaim mode).
>>
>> It seems that,
>>
>> If a demotion target has same distance to several current demotion
>> sources, the demotion target should be shared among the demotion
>> sources.
>
> Yes, and that is where this patch is useful.
>
>> And as Dave pointed out, we may eventually need a mechanism to override
>> the default demotion order generated automatically. So we can just use
>> some simple mechanism that makes sense in most cases in kernel
>> automatically. And leave the best demotion for users to some
>> customization mechanism.
>
> Yes, We need a mechanism to override the default demotion list prepared
> by the current implementation. PowerVM can have a cpu less dram node
> as well, which infact are not the right target for demotion because
> it is the fast memory. We need to distinguish between memory tiers
> so that slow memory can be utilized for the demotion even when there
> are fast memory only numa nodes.
>
> I think we may see implementations in future to override the default
> behavior e.g. when systems have both fast only and slow only memory
> nodes and in that case it will make sense to demote to slow memory
> only node even if it is far, but this patch is to put the current
> implementation to its intended design 'best distance based demotion
> targets'.
If this is a real problem for you already. How about implement it after
this work has been done?
Best Regards,
Huang, Ying
>> > As it can be seen above, node 3 can be demotion target for node
>> > 1 but existing implementation doesn't configure it that way. It
>> > is better to move pages from node 1 to node 3 instead of moving
>> > it from node 1 to swap.
>> >
>> > Signed-off-by: Jagdish Gediya <[email protected]>
>> > Signed-off-by: Aneesh Kumar K.V <[email protected]>
>>
>> Best Regards,
>> Huang, Ying
>>
>> [snip]
>>
> Best Regards,
> Jagdish
"Huang, Ying" <[email protected]> writes:
> "Aneesh Kumar K.V" <[email protected]> writes:
>
>> "Huang, Ying" <[email protected]> writes:
>>
>>> Hi, Jagdish,
>>>
>>> Jagdish Gediya <[email protected]> writes:
>>>
>>
>> ...
>>
>>>> e.g. with below NUMA topology, where node 0 & 1 are
>>>> cpu + dram nodes, node 2 & 3 are equally slower memory
>>>> only nodes, and node 4 is slowest memory only node,
>>>>
>>>> available: 5 nodes (0-4)
>>>> node 0 cpus: 0 1
>>>> node 0 size: n MB
>>>> node 0 free: n MB
>>>> node 1 cpus: 2 3
>>>> node 1 size: n MB
>>>> node 1 free: n MB
>>>> node 2 cpus:
>>>> node 2 size: n MB
>>>> node 2 free: n MB
>>>> node 3 cpus:
>>>> node 3 size: n MB
>>>> node 3 free: n MB
>>>> node 4 cpus:
>>>> node 4 size: n MB
>>>> node 4 free: n MB
>>>> node distances:
>>>> node 0 1 2 3 4
>>>> 0: 10 20 40 40 80
>>>> 1: 20 10 40 40 80
>>>> 2: 40 40 10 40 80
>>>> 3: 40 40 40 10 80
>>>> 4: 80 80 80 80 10
>>>>
>>>> The existing implementation gives below demotion targets,
>>>>
>>>> node demotion_target
>>>> 0 3, 2
>>>> 1 4
>>>> 2 X
>>>> 3 X
>>>> 4 X
>>>>
>>>> With this patch applied, below are the demotion targets,
>>>>
>>>> node demotion_target
>>>> 0 3, 2
>>>> 1 3, 2
>>>> 2 3
>>>> 3 4
>>>> 4 X
>>>
>>> For such machine, I think the perfect demotion order is,
>>>
>>> node demotion_target
>>> 0 2, 3
>>> 1 2, 3
>>> 2 4
>>> 3 4
>>> 4 X
>>
>> I guess the "equally slow nodes" is a confusing definition here. Now if the
>> system consists of 2 1GB equally slow memory and the firmware doesn't want to
>> differentiate between them, firmware can present a single NUMA node
>> with 2GB capacity? The fact that we are finding two NUMA nodes is a hint
>> that there is some difference between these two memory devices. This is
>> also captured by the fact that the distance between 2 and 3 is 40 and not 10.
>
> Do you have more information about this?
Not sure I follow the question there. I was checking shouldn't firmware
do a single NUMA node if two memory devices are of the same type? How will
optane present such a config? Both the DIMMs will have the same
proximity domain value and hence dax kmem will add them to the same NUMA
node?
If you are suggesting that firmware doesn't do that, then I agree with you
that a demotion target like the below is good.
node demotion_target
0 2, 3
1 2, 3
2 4
3 4
4 X
We can also achieve that with a smiple change as below.
@@ -3120,7 +3120,7 @@ static void __set_migration_target_nodes(void)
{
nodemask_t next_pass = NODE_MASK_NONE;
nodemask_t this_pass = NODE_MASK_NONE;
- nodemask_t used_targets = NODE_MASK_NONE;
+ nodemask_t this_pass_used_targets = NODE_MASK_NONE;
int node, best_distance;
/*
@@ -3141,17 +3141,20 @@ static void __set_migration_target_nodes(void)
/*
* To avoid cycles in the migration "graph", ensure
* that migration sources are not future targets by
- * setting them in 'used_targets'. Do this only
+ * setting them in 'this_pass_used_targets'. Do this only
* once per pass so that multiple source nodes can
* share a target node.
*
- * 'used_targets' will become unavailable in future
+ * 'this_pass_used_targets' will become unavailable in future
* passes. This limits some opportunities for
* multiple source nodes to share a destination.
*/
- nodes_or(used_targets, used_targets, this_pass);
+ nodes_or(this_pass_used_targets, this_pass_used_targets, this_pass);
for_each_node_mask(node, this_pass) {
+
+ nodemask_t used_targets = this_pass_used_targets;
+
best_distance = -1;
/*
"Aneesh Kumar K.V" <[email protected]> writes:
> "Huang, Ying" <[email protected]> writes:
>
>> "Aneesh Kumar K.V" <[email protected]> writes:
>>
>>> "Huang, Ying" <[email protected]> writes:
>>>
>>>> Hi, Jagdish,
>>>>
>>>> Jagdish Gediya <[email protected]> writes:
>>>>
>>>
>>> ...
>>>
>>>>> e.g. with below NUMA topology, where node 0 & 1 are
>>>>> cpu + dram nodes, node 2 & 3 are equally slower memory
>>>>> only nodes, and node 4 is slowest memory only node,
>>>>>
>>>>> available: 5 nodes (0-4)
>>>>> node 0 cpus: 0 1
>>>>> node 0 size: n MB
>>>>> node 0 free: n MB
>>>>> node 1 cpus: 2 3
>>>>> node 1 size: n MB
>>>>> node 1 free: n MB
>>>>> node 2 cpus:
>>>>> node 2 size: n MB
>>>>> node 2 free: n MB
>>>>> node 3 cpus:
>>>>> node 3 size: n MB
>>>>> node 3 free: n MB
>>>>> node 4 cpus:
>>>>> node 4 size: n MB
>>>>> node 4 free: n MB
>>>>> node distances:
>>>>> node 0 1 2 3 4
>>>>> 0: 10 20 40 40 80
>>>>> 1: 20 10 40 40 80
>>>>> 2: 40 40 10 40 80
>>>>> 3: 40 40 40 10 80
>>>>> 4: 80 80 80 80 10
>>>>>
>>>>> The existing implementation gives below demotion targets,
>>>>>
>>>>> node demotion_target
>>>>> 0 3, 2
>>>>> 1 4
>>>>> 2 X
>>>>> 3 X
>>>>> 4 X
>>>>>
>>>>> With this patch applied, below are the demotion targets,
>>>>>
>>>>> node demotion_target
>>>>> 0 3, 2
>>>>> 1 3, 2
>>>>> 2 3
>>>>> 3 4
>>>>> 4 X
>>>>
>>>> For such machine, I think the perfect demotion order is,
>>>>
>>>> node demotion_target
>>>> 0 2, 3
>>>> 1 2, 3
>>>> 2 4
>>>> 3 4
>>>> 4 X
>>>
>>> I guess the "equally slow nodes" is a confusing definition here. Now if the
>>> system consists of 2 1GB equally slow memory and the firmware doesn't want to
>>> differentiate between them, firmware can present a single NUMA node
>>> with 2GB capacity? The fact that we are finding two NUMA nodes is a hint
>>> that there is some difference between these two memory devices. This is
>>> also captured by the fact that the distance between 2 and 3 is 40 and not 10.
>>
>> Do you have more information about this?
>
> Not sure I follow the question there. I was checking shouldn't firmware
> do a single NUMA node if two memory devices are of the same type? How will
> optane present such a config? Both the DIMMs will have the same
> proximity domain value and hence dax kmem will add them to the same NUMA
> node?
Sorry for confusing. I just wanted to check whether you have more
information about the machine configuration above. The machines in my
hand have no complex NUMA topology as in the patch description.
> If you are suggesting that firmware doesn't do that, then I agree with you
> that a demotion target like the below is good.
>
> node demotion_target
> 0 2, 3
> 1 2, 3
> 2 4
> 3 4
> 4 X
>
> We can also achieve that with a smiple change as below.
Glad to see the demotion order can be implemented in a simple way.
My concern is that is it necessary to do this? If there are real
machines with the NUMA topology, then I think it's good to add the
support. But if not, why do we make the code complex unnecessarily?
I don't have these kind of machines, do you have and will have?
> @@ -3120,7 +3120,7 @@ static void __set_migration_target_nodes(void)
> {
> nodemask_t next_pass = NODE_MASK_NONE;
> nodemask_t this_pass = NODE_MASK_NONE;
> - nodemask_t used_targets = NODE_MASK_NONE;
> + nodemask_t this_pass_used_targets = NODE_MASK_NONE;
> int node, best_distance;
>
> /*
> @@ -3141,17 +3141,20 @@ static void __set_migration_target_nodes(void)
> /*
> * To avoid cycles in the migration "graph", ensure
> * that migration sources are not future targets by
> - * setting them in 'used_targets'. Do this only
> + * setting them in 'this_pass_used_targets'. Do this only
> * once per pass so that multiple source nodes can
> * share a target node.
> *
> - * 'used_targets' will become unavailable in future
> + * 'this_pass_used_targets' will become unavailable in future
> * passes. This limits some opportunities for
> * multiple source nodes to share a destination.
> */
> - nodes_or(used_targets, used_targets, this_pass);
> + nodes_or(this_pass_used_targets, this_pass_used_targets, this_pass);
>
> for_each_node_mask(node, this_pass) {
> +
> + nodemask_t used_targets = this_pass_used_targets;
> +
> best_distance = -1;
>
> /*
Best Regards,
Huang, Ying
"Huang, Ying" <[email protected]> writes:
> "Aneesh Kumar K.V" <[email protected]> writes:
>
>> "Huang, Ying" <[email protected]> writes:
>>
>>> "Aneesh Kumar K.V" <[email protected]> writes:
>>>
>>>> "Huang, Ying" <[email protected]> writes:
>>>>
>>>>> Hi, Jagdish,
>>>>>
>>>>> Jagdish Gediya <[email protected]> writes:
>>>>>
>>>>
>>>> ...
>>>>
>>>>>> e.g. with below NUMA topology, where node 0 & 1 are
>>>>>> cpu + dram nodes, node 2 & 3 are equally slower memory
>>>>>> only nodes, and node 4 is slowest memory only node,
>>>>>>
>>>>>> available: 5 nodes (0-4)
>>>>>> node 0 cpus: 0 1
>>>>>> node 0 size: n MB
>>>>>> node 0 free: n MB
>>>>>> node 1 cpus: 2 3
>>>>>> node 1 size: n MB
>>>>>> node 1 free: n MB
>>>>>> node 2 cpus:
>>>>>> node 2 size: n MB
>>>>>> node 2 free: n MB
>>>>>> node 3 cpus:
>>>>>> node 3 size: n MB
>>>>>> node 3 free: n MB
>>>>>> node 4 cpus:
>>>>>> node 4 size: n MB
>>>>>> node 4 free: n MB
>>>>>> node distances:
>>>>>> node 0 1 2 3 4
>>>>>> 0: 10 20 40 40 80
>>>>>> 1: 20 10 40 40 80
>>>>>> 2: 40 40 10 40 80
>>>>>> 3: 40 40 40 10 80
>>>>>> 4: 80 80 80 80 10
>>>>>>
>>>>>> The existing implementation gives below demotion targets,
>>>>>>
>>>>>> node demotion_target
>>>>>> 0 3, 2
>>>>>> 1 4
>>>>>> 2 X
>>>>>> 3 X
>>>>>> 4 X
>>>>>>
>>>>>> With this patch applied, below are the demotion targets,
>>>>>>
>>>>>> node demotion_target
>>>>>> 0 3, 2
>>>>>> 1 3, 2
>>>>>> 2 3
>>>>>> 3 4
>>>>>> 4 X
>>>>>
>>>>> For such machine, I think the perfect demotion order is,
>>>>>
>>>>> node demotion_target
>>>>> 0 2, 3
>>>>> 1 2, 3
>>>>> 2 4
>>>>> 3 4
>>>>> 4 X
>>>>
>>>> I guess the "equally slow nodes" is a confusing definition here. Now if the
>>>> system consists of 2 1GB equally slow memory and the firmware doesn't want to
>>>> differentiate between them, firmware can present a single NUMA node
>>>> with 2GB capacity? The fact that we are finding two NUMA nodes is a hint
>>>> that there is some difference between these two memory devices. This is
>>>> also captured by the fact that the distance between 2 and 3 is 40 and not 10.
>>>
>>> Do you have more information about this?
>>
>> Not sure I follow the question there. I was checking shouldn't firmware
>> do a single NUMA node if two memory devices are of the same type? How will
>> optane present such a config? Both the DIMMs will have the same
>> proximity domain value and hence dax kmem will add them to the same NUMA
>> node?
>
> Sorry for confusing. I just wanted to check whether you have more
> information about the machine configuration above. The machines in my
> hand have no complex NUMA topology as in the patch description.
Even with simple topologies like below
available: 3 nodes (0-2)
node 0 cpus: 0 1
node 0 size: 4046 MB
node 0 free: 3478 MB
node 1 cpus: 2 3
node 1 size: 4090 MB
node 1 free: 3430 MB
node 2 cpus:
node 2 size: 4074 MB
node 2 free: 4037 MB
node distances:
node 0 1 2
0: 10 20 40
1: 20 10 40
2: 40 40 10
With current code we get demotion targets assigned as below
[ 0.337307] Demotion nodes for Node 0: 2
[ 0.337351] Demotion nodes for Node 1:
[ 0.337380] Demotion nodes for Node 2:
I guess we should fix that to be below?
[ 0.344554] Demotion nodes for Node 0: 2
[ 0.344605] Demotion nodes for Node 1: 2
[ 0.344638] Demotion nodes for Node 2:
Most of the tests we are doing are using Qemu to simulate this. We
started looking at this to avoid using demotion completely when slow
memory is not present. ie, we should have a different way to identify
demotion targets other than node_states[N_MEMORY]. Virtualized platforms
can have configs with memory only NUMA nodes with DRAM and we don't
want to consider those as demotion targets.
While we are at it can you let us know how topology will look on a
system with two optane DIMMs? Do both appear with the same
target_node?
>
>> If you are suggesting that firmware doesn't do that, then I agree with you
>> that a demotion target like the below is good.
>>
>> node demotion_target
>> 0 2, 3
>> 1 2, 3
>> 2 4
>> 3 4
>> 4 X
>>
>> We can also achieve that with a smiple change as below.
>
> Glad to see the demotion order can be implemented in a simple way.
>
> My concern is that is it necessary to do this? If there are real
> machines with the NUMA topology, then I think it's good to add the
> support. But if not, why do we make the code complex unnecessarily?
>
> I don't have these kind of machines, do you have and will have?
>
Based on the above, we still need to get the simpler fix merged right?
>> @@ -3120,7 +3120,7 @@ static void __set_migration_target_nodes(void)
>> {
>> nodemask_t next_pass = NODE_MASK_NONE;
>> nodemask_t this_pass = NODE_MASK_NONE;
>> - nodemask_t used_targets = NODE_MASK_NONE;
>> + nodemask_t this_pass_used_targets = NODE_MASK_NONE;
>> int node, best_distance;
>>
>> /*
>> @@ -3141,17 +3141,20 @@ static void __set_migration_target_nodes(void)
>> /*
>> * To avoid cycles in the migration "graph", ensure
>> * that migration sources are not future targets by
>> - * setting them in 'used_targets'. Do this only
>> + * setting them in 'this_pass_used_targets'. Do this only
>> * once per pass so that multiple source nodes can
>> * share a target node.
>> *
>> - * 'used_targets' will become unavailable in future
>> + * 'this_pass_used_targets' will become unavailable in future
>> * passes. This limits some opportunities for
>> * multiple source nodes to share a destination.
>> */
>> - nodes_or(used_targets, used_targets, this_pass);
>> + nodes_or(this_pass_used_targets, this_pass_used_targets, this_pass);
>>
>> for_each_node_mask(node, this_pass) {
>> +
>> + nodemask_t used_targets = this_pass_used_targets;
>> +
>> best_distance = -1;
>>
>> /*
>
> Best Regards,
> Huang, Ying
"Aneesh Kumar K.V" <[email protected]> writes:
> "Huang, Ying" <[email protected]> writes:
>
>> "Aneesh Kumar K.V" <[email protected]> writes:
>>
>>> "Huang, Ying" <[email protected]> writes:
>>>
>>>> "Aneesh Kumar K.V" <[email protected]> writes:
>>>>
>>>>> "Huang, Ying" <[email protected]> writes:
>>>>>
>>>>>> Hi, Jagdish,
>>>>>>
>>>>>> Jagdish Gediya <[email protected]> writes:
>>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>>>> e.g. with below NUMA topology, where node 0 & 1 are
>>>>>>> cpu + dram nodes, node 2 & 3 are equally slower memory
>>>>>>> only nodes, and node 4 is slowest memory only node,
>>>>>>>
>>>>>>> available: 5 nodes (0-4)
>>>>>>> node 0 cpus: 0 1
>>>>>>> node 0 size: n MB
>>>>>>> node 0 free: n MB
>>>>>>> node 1 cpus: 2 3
>>>>>>> node 1 size: n MB
>>>>>>> node 1 free: n MB
>>>>>>> node 2 cpus:
>>>>>>> node 2 size: n MB
>>>>>>> node 2 free: n MB
>>>>>>> node 3 cpus:
>>>>>>> node 3 size: n MB
>>>>>>> node 3 free: n MB
>>>>>>> node 4 cpus:
>>>>>>> node 4 size: n MB
>>>>>>> node 4 free: n MB
>>>>>>> node distances:
>>>>>>> node 0 1 2 3 4
>>>>>>> 0: 10 20 40 40 80
>>>>>>> 1: 20 10 40 40 80
>>>>>>> 2: 40 40 10 40 80
>>>>>>> 3: 40 40 40 10 80
>>>>>>> 4: 80 80 80 80 10
>>>>>>>
>>>>>>> The existing implementation gives below demotion targets,
>>>>>>>
>>>>>>> node demotion_target
>>>>>>> 0 3, 2
>>>>>>> 1 4
>>>>>>> 2 X
>>>>>>> 3 X
>>>>>>> 4 X
>>>>>>>
>>>>>>> With this patch applied, below are the demotion targets,
>>>>>>>
>>>>>>> node demotion_target
>>>>>>> 0 3, 2
>>>>>>> 1 3, 2
>>>>>>> 2 3
>>>>>>> 3 4
>>>>>>> 4 X
>>>>>>
>>>>>> For such machine, I think the perfect demotion order is,
>>>>>>
>>>>>> node demotion_target
>>>>>> 0 2, 3
>>>>>> 1 2, 3
>>>>>> 2 4
>>>>>> 3 4
>>>>>> 4 X
>>>>>
>>>>> I guess the "equally slow nodes" is a confusing definition here. Now if the
>>>>> system consists of 2 1GB equally slow memory and the firmware doesn't want to
>>>>> differentiate between them, firmware can present a single NUMA node
>>>>> with 2GB capacity? The fact that we are finding two NUMA nodes is a hint
>>>>> that there is some difference between these two memory devices. This is
>>>>> also captured by the fact that the distance between 2 and 3 is 40 and not 10.
>>>>
>>>> Do you have more information about this?
>>>
>>> Not sure I follow the question there. I was checking shouldn't firmware
>>> do a single NUMA node if two memory devices are of the same type? How will
>>> optane present such a config? Both the DIMMs will have the same
>>> proximity domain value and hence dax kmem will add them to the same NUMA
>>> node?
>>
>> Sorry for confusing. I just wanted to check whether you have more
>> information about the machine configuration above. The machines in my
>> hand have no complex NUMA topology as in the patch description.
>
>
> Even with simple topologies like below
>
> available: 3 nodes (0-2)
> node 0 cpus: 0 1
> node 0 size: 4046 MB
> node 0 free: 3478 MB
> node 1 cpus: 2 3
> node 1 size: 4090 MB
> node 1 free: 3430 MB
> node 2 cpus:
> node 2 size: 4074 MB
> node 2 free: 4037 MB
> node distances:
> node 0 1 2
> 0: 10 20 40
> 1: 20 10 40
> 2: 40 40 10
>
> With current code we get demotion targets assigned as below
>
> [ 0.337307] Demotion nodes for Node 0: 2
> [ 0.337351] Demotion nodes for Node 1:
> [ 0.337380] Demotion nodes for Node 2:
>
> I guess we should fix that to be below?
>
> [ 0.344554] Demotion nodes for Node 0: 2
> [ 0.344605] Demotion nodes for Node 1: 2
> [ 0.344638] Demotion nodes for Node 2:
If the cross-socket link has enough bandwidth to accommodate the PMEM
throughput, the new one is better. If it hasn't, the old one may be
better. So, I think we need some kind of user space overridden support
here. Right?
> Most of the tests we are doing are using Qemu to simulate this. We
> started looking at this to avoid using demotion completely when slow
> memory is not present. ie, we should have a different way to identify
> demotion targets other than node_states[N_MEMORY]. Virtualized platforms
> can have configs with memory only NUMA nodes with DRAM and we don't
> want to consider those as demotion targets.
Even if the demotion targets are set for some node, the demotion will
not work before enabling demotion via sysfs
(/sys/kernel/mm/numa/demotion_enabled). So for system without slow
memory, just don't enable demotion.
> While we are at it can you let us know how topology will look on a
> system with two optane DIMMs? Do both appear with the same
> target_node?
In my test system, multiple optane DIMMs in one socket will be
represented as one NUMA node.
I remember Baolin has different configuration.
Hi, Baolin, Can you provide some information about this?
>>
>>> If you are suggesting that firmware doesn't do that, then I agree with you
>>> that a demotion target like the below is good.
>>>
>>> node demotion_target
>>> 0 2, 3
>>> 1 2, 3
>>> 2 4
>>> 3 4
>>> 4 X
>>>
>>> We can also achieve that with a smiple change as below.
>>
>> Glad to see the demotion order can be implemented in a simple way.
>>
>> My concern is that is it necessary to do this? If there are real
>> machines with the NUMA topology, then I think it's good to add the
>> support. But if not, why do we make the code complex unnecessarily?
>>
>> I don't have these kind of machines, do you have and will have?
>>
>
>
> Based on the above, we still need to get the simpler fix merged right?
Or user overridden support?
Best Regards,
Huang, Ying
[snip]
On Wed, 30 Mar 2022 22:06:52 +0530
Jagdish Gediya <[email protected]> wrote:
> Hi Huang,
>
> On Wed, Mar 30, 2022 at 02:46:51PM +0800, Huang, Ying wrote:
> > Hi, Jagdish,
> >
> > Jagdish Gediya <[email protected]> writes:
> >
> > > The current implementation to identify the demotion
> > > targets limits some of the opportunities to share
> > > the demotion targets between multiple source nodes.
> >
> > Yes. It sounds reasonable to share demotion targets among multiple
> > source nodes.
> >
> > One question, are example machines below are real hardware now or in
> > near future? Or you just think they are possible?
>
> They are not real hardware right now, they are the future possibilities.
I'll strengthen that a bit to say they are highly likely to turn up
fairly soon. Often they will be result of specific interleaving decisions
and might not come from SRAT (e.g. might be added later as a result of
CXL discovery) but the principal will be the same. Also, in some
cases the firmware will have done the CXL setup so it will be via SRAT.
example 1:
> > e.g. with below NUMA topology, where node 0 & 1 are
> > cpu + dram nodes, node 2 & 3 are equally slower memory
> > only nodes, and node 4 is slowest memory only node,
> >
Couple of near term examples of systems that will look like this.
2 socket system, each socket has DRAM (0,1) + NVDIMM (2,3) being
used as DRAM.
Also CXL attached memory and to get maximum bandwidth to a large
remote pool, interleave across host bridges in the two sockets
(Node 4)
An alternative for node 4 is a that the system is using an IO expander
bridge on the CPU interconnect (effectively a CPU less CPU :)
Example 2:
> > e.g. with below NUMA topology, where node 0, 1 & 2 are
> > cpu + dram nodes and node 3 is slow memory node,
> >
3 CPU socket machines are still unusual, but the 2 or 4 socket
equivalents are simplifications of example 1.
Example 3:
> > with below NUMA topology, where node 0 & 2 are cpu + dram
> > nodes and node 1 & 3 are slow memory nodes,
I believe this is what today's simple DRAM + NVDIMM (as cheap
DRAM) 2 sockets servers look like.
Example 4:
> Another example, node 0 & 2 are cpu + dram nodes and node 1 are slow
> memory node near node 0,
>
Normal system with CXL attached DRAM below an RP in node 0
...
Jonathan
On 3/31/2022 4:58 PM, Huang, Ying wrote:
> "Aneesh Kumar K.V" <[email protected]> writes:
>
>> "Huang, Ying" <[email protected]> writes:
>>
>>> "Aneesh Kumar K.V" <[email protected]> writes:
>>>
>>>> "Huang, Ying" <[email protected]> writes:
>>>>
>>>>> "Aneesh Kumar K.V" <[email protected]> writes:
>>>>>
>>>>>> "Huang, Ying" <[email protected]> writes:
>>>>>>
>>>>>>> Hi, Jagdish,
>>>>>>>
>>>>>>> Jagdish Gediya <[email protected]> writes:
>>>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>>> e.g. with below NUMA topology, where node 0 & 1 are
>>>>>>>> cpu + dram nodes, node 2 & 3 are equally slower memory
>>>>>>>> only nodes, and node 4 is slowest memory only node,
>>>>>>>>
>>>>>>>> available: 5 nodes (0-4)
>>>>>>>> node 0 cpus: 0 1
>>>>>>>> node 0 size: n MB
>>>>>>>> node 0 free: n MB
>>>>>>>> node 1 cpus: 2 3
>>>>>>>> node 1 size: n MB
>>>>>>>> node 1 free: n MB
>>>>>>>> node 2 cpus:
>>>>>>>> node 2 size: n MB
>>>>>>>> node 2 free: n MB
>>>>>>>> node 3 cpus:
>>>>>>>> node 3 size: n MB
>>>>>>>> node 3 free: n MB
>>>>>>>> node 4 cpus:
>>>>>>>> node 4 size: n MB
>>>>>>>> node 4 free: n MB
>>>>>>>> node distances:
>>>>>>>> node 0 1 2 3 4
>>>>>>>> 0: 10 20 40 40 80
>>>>>>>> 1: 20 10 40 40 80
>>>>>>>> 2: 40 40 10 40 80
>>>>>>>> 3: 40 40 40 10 80
>>>>>>>> 4: 80 80 80 80 10
>>>>>>>>
>>>>>>>> The existing implementation gives below demotion targets,
>>>>>>>>
>>>>>>>> node demotion_target
>>>>>>>> 0 3, 2
>>>>>>>> 1 4
>>>>>>>> 2 X
>>>>>>>> 3 X
>>>>>>>> 4 X
>>>>>>>>
>>>>>>>> With this patch applied, below are the demotion targets,
>>>>>>>>
>>>>>>>> node demotion_target
>>>>>>>> 0 3, 2
>>>>>>>> 1 3, 2
>>>>>>>> 2 3
>>>>>>>> 3 4
>>>>>>>> 4 X
>>>>>>>
>>>>>>> For such machine, I think the perfect demotion order is,
>>>>>>>
>>>>>>> node demotion_target
>>>>>>> 0 2, 3
>>>>>>> 1 2, 3
>>>>>>> 2 4
>>>>>>> 3 4
>>>>>>> 4 X
>>>>>>
>>>>>> I guess the "equally slow nodes" is a confusing definition here. Now if the
>>>>>> system consists of 2 1GB equally slow memory and the firmware doesn't want to
>>>>>> differentiate between them, firmware can present a single NUMA node
>>>>>> with 2GB capacity? The fact that we are finding two NUMA nodes is a hint
>>>>>> that there is some difference between these two memory devices. This is
>>>>>> also captured by the fact that the distance between 2 and 3 is 40 and not 10.
>>>>>
>>>>> Do you have more information about this?
>>>>
>>>> Not sure I follow the question there. I was checking shouldn't firmware
>>>> do a single NUMA node if two memory devices are of the same type? How will
>>>> optane present such a config? Both the DIMMs will have the same
>>>> proximity domain value and hence dax kmem will add them to the same NUMA
>>>> node?
>>>
>>> Sorry for confusing. I just wanted to check whether you have more
>>> information about the machine configuration above. The machines in my
>>> hand have no complex NUMA topology as in the patch description.
>>
>>
>> Even with simple topologies like below
>>
>> available: 3 nodes (0-2)
>> node 0 cpus: 0 1
>> node 0 size: 4046 MB
>> node 0 free: 3478 MB
>> node 1 cpus: 2 3
>> node 1 size: 4090 MB
>> node 1 free: 3430 MB
>> node 2 cpus:
>> node 2 size: 4074 MB
>> node 2 free: 4037 MB
>> node distances:
>> node 0 1 2
>> 0: 10 20 40
>> 1: 20 10 40
>> 2: 40 40 10
>>
>> With current code we get demotion targets assigned as below
>>
>> [ 0.337307] Demotion nodes for Node 0: 2
>> [ 0.337351] Demotion nodes for Node 1:
>> [ 0.337380] Demotion nodes for Node 2:
>>
>> I guess we should fix that to be below?
>>
>> [ 0.344554] Demotion nodes for Node 0: 2
>> [ 0.344605] Demotion nodes for Node 1: 2
>> [ 0.344638] Demotion nodes for Node 2:
>
> If the cross-socket link has enough bandwidth to accommodate the PMEM
> throughput, the new one is better. If it hasn't, the old one may be
> better. So, I think we need some kind of user space overridden support
> here. Right?
>
>> Most of the tests we are doing are using Qemu to simulate this. We
>> started looking at this to avoid using demotion completely when slow
>> memory is not present. ie, we should have a different way to identify
>> demotion targets other than node_states[N_MEMORY]. Virtualized platforms
>> can have configs with memory only NUMA nodes with DRAM and we don't
>> want to consider those as demotion targets.
>
> Even if the demotion targets are set for some node, the demotion will
> not work before enabling demotion via sysfs
> (/sys/kernel/mm/numa/demotion_enabled). So for system without slow
> memory, just don't enable demotion.
>
>> While we are at it can you let us know how topology will look on a
>> system with two optane DIMMs? Do both appear with the same
>> target_node?
>
> In my test system, multiple optane DIMMs in one socket will be
> represented as one NUMA node.
>
> I remember Baolin has different configuration.
>
> Hi, Baolin, Can you provide some information about this?
Sure. We have real machines with 2 optane DIMMs, and they are
represented as 2 numa nodes. So we want to support the target demotion
nodes can be multiple.
available: 3 nodes (0-2)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 62153 MB
node 0 free: 447 MB
node 1 cpus:
node 1 size: 126969 MB
node 1 free: 84099 MB
node 2 cpus:
node 2 size: 127006 MB
node 2 free: 126925 MB
node distances:
node 0 1 2
0: 10 20 20
1: 20 10 20
2: 20 20 10