From: Jagdish Gediya <jvgediya@linux.ibm.com>
To: "ying.huang@intel.com" <ying.huang@intel.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, baolin.wang@linux.alibaba.com,
dave.hansen@linux.intel.com, aneesh.kumar@linux.ibm.com,
shy828301@gmail.com, weixugc@google.com, gthelen@google.com,
dan.j.williams@intel.com
Subject: Re: [PATCH v3 0/7] mm: demotion: Introduce new node state N_DEMOTION_TARGETS
Date: Mon, 25 Apr 2022 16:45:38 +0530 [thread overview]
Message-ID: <YmaC2jw6WaQ4X+8W@li-6e1fa1cc-351b-11b2-a85c-b897023bb5f3.ibm.com> (raw)
In-Reply-To: <4b986b46afb2fe888c127d8758221d0f0d3ec55f.camel@intel.com>
On Sun, Apr 24, 2022 at 11:19:53AM +0800, ying.huang@intel.com wrote:
> On Sat, 2022-04-23 at 01:25 +0530, Jagdish Gediya wrote:
> > Some systems(e.g. PowerVM) can have both DRAM(fast memory) only
> > NUMA node which are N_MEMORY and slow memory(persistent memory)
> > only NUMA node which are also N_MEMORY. As the current demotion
> > target finding algorithm works based on N_MEMORY and best distance,
> > it will choose DRAM only NUMA node as demotion target instead of
> > persistent memory node on such systems. If DRAM only NUMA node is
> > filled with demoted pages then at some point new allocations can
> > start falling to persistent memory, so basically cold pages are in
> > fast memor (due to demotion) and new pages are in slow memory, this
> > is why persistent memory nodes should be utilized for demotion and
> > dram node should be avoided for demotion so that they can be used
> > for new allocations.
> >
> > Current implementation can work fine on the system where the memory
> > only numa nodes are possible only for persistent/slow memory but it
> > is not suitable for the like of systems mentioned above.
>
> Can you share the NUMA topology information of your machine? And the
> demotion order before and after your change?
>
> Whether it's good to use the PMEM nodes as the demotion targets of the
> DRAM-only node too?
$ numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 14272 MB
node 0 free: 13392 MB
node 1 cpus:
node 1 size: 2028 MB
node 1 free: 1971 MB
node distances:
node 0 1
0: 10 40
1: 40 10
1) without N_DEMOTION_TARGETS patch series, 1 is demotion target
for 0 even when 1 is DRAM node and there is no demotion targets for 1.
$ cat /sys/bus/nd/devices/dax0.0/target_node
2
$
# cd /sys/bus/dax/drivers/
:/sys/bus/dax/drivers# ls
device_dax kmem
:/sys/bus/dax/drivers# cd device_dax/
:/sys/bus/dax/drivers/device_dax# echo dax0.0 > unbind
:/sys/bus/dax/drivers/device_dax# echo dax0.0 > ../kmem/new_id
:/sys/bus/dax/drivers/device_dax# numactl -H
available: 3 nodes (0-2)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 14272 MB
node 0 free: 13380 MB
node 1 cpus:
node 1 size: 2028 MB
node 1 free: 1961 MB
node 2 cpus:
node 2 size: 0 MB
node 2 free: 0 MB
node distances:
node 0 1 2
0: 10 40 80
1: 40 10 80
2: 80 80 10
2) Once this new node brought online, without N_DEMOTION_TARGETS
patch series, 1 is demotion target for 0 and 2 is demotion target
for 1.
With this patch series applied,
1) No demotion target for either 0 or 1 before dax device is online
2) 2 is demotion target for both 0 and 1 after dax device is online.
> Best Regards,
> Huang, Ying
>
> > This patch series introduces the new node state N_DEMOTION_TARGETS,
> > which is used to distinguish the nodes which can be used as demotion
> > targets, node_states[N_DEMOTION_TARGETS] is used to hold the list of
> > nodes which can be used as demotion targets.
> >
> > node state N_DEMOTION_TARGETS is also set from the dax kmem driver,
> > certain type of memory which registers through dax kmem (e.g. HBM)
> > may not be the right choices for demotion so in future they should
> > be distinguished based on certain attributes and dax kmem driver
> > should avoid setting them as N_DEMOTION_TARGETS, however current
> > implementation also doesn't distinguish any such memory and it
> > considers all N_MEMORY as demotion targets so this patch series
> > doesn't modify the current behavior.
> >
> > below command can be used to view the available demotion targets in
> > the system,
> >
> > $ cat /sys/devices/system/node/demotion_targets
> >
> > This patch series sets N_DEMOTION_TARGET from dax device kmem driver,
> > It may be possible that some memory node desired as demotion target
> > is not detected in the system from dax-device kmem probe path. It is
> > also possible that some of the dax-devices are not preferred as
> > demotion target e.g. HBM, for such devices, node shouldn't be set to
> > N_DEMOTION_TARGETS, so support is also added to set the demotion
> > target list from user space so that default behavior can be overridden
> > to avoid or add specific node to demotion targets manually.
> >
> > Override the demotion targets in the system (which sets the
> > node_states[N_DEMOTION_TARGETS] in kernel),
> > $ echo <node list> > /sys/devices/system/node/demotion_targets
> >
> > As by default node attributes under /sys/devices/system/node/ are read-
> > only, support is added to write node_states[] via sysfs so that
> > node_states[N_DEMOTION_TARGETS] can be modified from user space via
> > sysfs.
> >
> > It is also helpful to know per node demotion target path prepared by
> > kernel to understand the demotion behaviour during reclaim, so this
> > patch series also adds a /sys/devices/system/node/nodeX/demotion_targets
> > interface to view per-node demotion targets via sysfs.
> >
> > Current code which sets migration targets is modified in
> > this patch series to avoid some of the limitations on the demotion
> > target sharing and to use N_DEMOTION_TARGETS only nodes while
> > finding demotion targets.
> >
> > Changelog
> > ----------
> >
> > v2:
> > In v1, only 1st patch of this patch series was sent, which was
> > implemented to avoid some of the limitations on the demotion
> > target sharing, however for certain numa topology, the demotion
> > targets found by that patch was not most optimal, so 1st patch
> > in this series is modified according to suggestions from Huang
> > and Baolin. Different examples of demotion list comparasion
> > between existing implementation and changed implementation can
> > be found in the commit message of 1st patch.
> >
> > v3:
> > - Modify patch 1 subject to make it more specific
> > - Remove /sys/kernel/mm/numa/demotion_targets interface, use
> > /sys/devices/system/node/demotion_targets instead and make
> > it writable to override node_states[N_DEMOTION_TARGETS].
> > - Add support to view per node demotion targets via sysfs
> >
> > Jagdish Gediya (8):
> > mm: demotion: Fix demotion targets sharing among sources
> > mm: demotion: Add new node state N_DEMOTION_TARGETS
> > drivers/base/node: Add support to write node_states[] via sysfs
> > device-dax/kmem: Set node state as N_DEMOTION_TARGETS
> > mm: demotion: Build demotion list based on N_DEMOTION_TARGETS
> > mm: demotion: expose per-node demotion targets via sysfs
> > docs: numa: Add documentation for demotion
> >
> > Documentation/admin-guide/mm/index.rst | 1 +
> > .../admin-guide/mm/numa_demotion.rst | 57 +++++++++++++++
> > drivers/base/node.c | 70 ++++++++++++++++---
> > drivers/dax/kmem.c | 2 +
> > include/linux/migrate.h | 1 +
> > include/linux/nodemask.h | 1 +
> > mm/migrate.c | 54 ++++++++++----
> > 7 files changed, 162 insertions(+), 24 deletions(-)
> > create mode 100644 Documentation/admin-guide/mm/numa_demotion.rst
> >
>
>
>
next prev parent reply other threads:[~2022-04-25 11:15 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 19:55 [PATCH v3 0/7] mm: demotion: Introduce new node state N_DEMOTION_TARGETS Jagdish Gediya
2022-04-22 19:55 ` [PATCH v3 1/7] mm: demotion: Fix demotion targets sharing among sources Jagdish Gediya
2022-04-24 3:25 ` ying.huang
2022-04-25 9:32 ` Jagdish Gediya
2022-04-26 7:26 ` ying.huang
2022-04-22 19:55 ` [PATCH v3 2/7] mm: demotion: Add new node state N_DEMOTION_TARGETS Jagdish Gediya
2022-04-22 20:29 ` Wei Xu
2022-04-22 19:55 ` [PATCH v3 3/7] drivers/base/node: Add support to write node_states[] via sysfs Jagdish Gediya
2022-04-22 20:32 ` Wei Xu
2022-04-24 6:25 ` Aneesh Kumar K.V
2022-04-25 9:42 ` Jagdish Gediya
2022-04-24 6:29 ` ying.huang
2022-04-22 19:55 ` [PATCH v3 4/7] device-dax/kmem: Set node state as N_DEMOTION_TARGETS Jagdish Gediya
2022-04-22 20:34 ` Wei Xu
2022-04-22 19:55 ` [PATCH v3 5/7] mm: demotion: Build demotion list based on N_DEMOTION_TARGETS Jagdish Gediya
2022-04-22 20:39 ` Wei Xu
2022-04-22 19:55 ` [PATCH v3 6/7] mm: demotion: expose per-node demotion targets via sysfs Jagdish Gediya
2022-04-22 20:47 ` Wei Xu
2022-04-23 7:30 ` kernel test robot
2022-04-23 8:38 ` kernel test robot
2022-04-22 19:55 ` [PATCH v3 7/7] docs: numa: Add documentation for demotion Jagdish Gediya
2022-04-24 3:19 ` [PATCH v3 0/7] mm: demotion: Introduce new node state N_DEMOTION_TARGETS ying.huang
2022-04-25 11:15 ` Jagdish Gediya [this message]
2022-04-25 13:57 ` Jonathan Cameron
2022-04-25 14:44 ` Aneesh Kumar K V
2022-04-26 10:43 ` Jonathan Cameron
2022-04-27 1:29 ` ying.huang
2022-04-27 2:57 ` Aneesh Kumar K V
2022-04-27 3:34 ` ying.huang
2022-04-25 14:53 ` Aneesh Kumar K V
2022-04-26 10:37 ` Jonathan Cameron
2022-04-26 7:55 ` ying.huang
2022-04-26 9:07 ` Aneesh Kumar K V
2022-04-26 9:10 ` ying.huang
2022-04-26 9:37 ` Jagdish Gediya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YmaC2jw6WaQ4X+8W@li-6e1fa1cc-351b-11b2-a85c-b897023bb5f3.ibm.com \
--to=jvgediya@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gthelen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shy828301@gmail.com \
--cc=weixugc@google.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).