[lkml]   [2022]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH RFC lsfmm 0/6] mm: proactive reclaim and memory tiering topics

With the increasing popularity of memory tiering, the idea of this series is to trigger
some discussion around David's[1] system-wide proactive reclaim beyond memcg[2] as well
as sysfs as the interface for exporting system-wide tiering information[2]. I am
hoping this can be discussed at LSFMM, and while I know many are interested in tiering
subjects in general, I have not seen anyone bring this up in the list.

There has been some initial discussion towards the need to expose system-wide tiering
information to userspace. I thought I'd start with two sysfs files as a node attribute
that exports the demotion_node as well as whether or not the node is fast memory. This
was considered (and I agree) better than a new /sys/devices/system/tier/tierN/ interface.
So, are we going to go this route? If so, what further information is useful for users?
Does having instead a /sys/devices/system/node/nodeN/reclaim/ make sense?

Applies against Linus' current tree and has only been _gently_ tested.


Davidlohr Bueso (6):
drivers/base/node: cleanup register_node()
mm/vmscan: use node_is_toptier helper in node_reclaim
mm: make __node_reclaim() more flexible
mm: introduce per-node proactive reclaim interface
mm/migration: export demotion_path of a node via sysfs
mm/migrate: export whether or not tier is toptier in sysfs

Documentation/ABI/stable/sysfs-devices-node | 22 ++++
drivers/base/node.c | 68 ++++++++++--
include/linux/migrate.h | 15 +++
include/linux/swap.h | 16 +++
include/trace/events/vmscan.h | 12 +--
mm/migrate.c | 15 +--
mm/vmscan.c | 108 +++++++++++++++-----
7 files changed, 206 insertions(+), 50 deletions(-)


 \ /
  Last update: 2022-04-16 07:40    [W:0.272 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site