Why cannot we start simple and build from there? In other words I
do not
think we really need anything like N_CPU_MEM at all.
In this patchset N_CPU_MEM is used to tell us what nodes are cpuless
nodes.
They would be the preferred demotion target. Of course, we could
rely on
firmware to just demote to the next best node, but it may be a
"preferred"
node, if so I don't see too much benefit achieved by demotion. Am I
missing
anything?
Why cannot we simply demote in the proximity order? Why do you make
cpuless nodes so special? If other close nodes are vacant then just use
them.
And, I'm supposed we agree to *not* migrate from PMEM node (cpuless
node) to any other node on reclaim path, right? If so we need know if
the current node is DRAM node or PMEM node. If DRAM node, do demotion;
if PMEM node, do swap. So, using N_CPU_MEM to tell us if the current
node is DRAM node or not.
We could. But, this raises another question, would we prefer to just
demote to the next fallback node (just try once), if it is contended,
then just swap (i.e. DRAM0 -> PMEM0 -> Swap); or would we prefer to
try all the nodes in the fallback order to find the first less
contended one (i.e. DRAM0 -> PMEM0 -> DRAM1 -> PMEM1 -> Swap)?
|------| |------| |------| |------|
|PMEM0|---|DRAM0| --- CPU0 --- CPU1 --- |DRAM1| --- |PMEM1|
|------| |------| |------| |------|
The first one sounds simpler, and the current implementation does so
and this needs find out the closest PMEM node by recognizing cpuless
node.
If we prefer go with the second option, it is definitely unnecessary
to specialize any node.
