From: kaiyang2@cs.cmu.edu
To: linux-mm@kvack.org, cgroups@vger.kernel.org
Cc: roman.gushchin@linux.dev, shakeel.butt@linux.dev,
muchun.song@linux.dev, akpm@linux-foundation.org,
mhocko@kernel.org, nehagholkar@meta.com, abhishekd@meta.com,
hannes@cmpxchg.org, weixugc@google.com, rientjes@google.com,
Kaiyang Zhao <kaiyang2@cs.cmu.edu>
Subject: [RFC PATCH 0/4] memory tiering fairness by per-cgroup control of promotion and demotion
Date: Fri, 20 Sep 2024 22:11:47 +0000 [thread overview]
Message-ID: <20240920221202.1734227-1-kaiyang2@cs.cmu.edu> (raw)
From: Kaiyang Zhao <kaiyang2@cs.cmu.edu>
Currently in Linux, there is no concept of fairness in memory tiering. Depending
on the memory usage and access patterns of other colocated applications, an
application cannot be sure of how much memory in which tier it will get, and how
much its performance will suffer or benefit.
Fairness is, however, important in a multi-tenant system. For example, an
application may need to meet a certain tail latency requirement, which can be
difficult to satisfy without x amount of frequently accessed pages in top-tier
memory. Similarly, an application may want to declare a minimum throughput when
running on a system for capacity planning purposes, but without fairness
controls in memory tiering its throughput can fluctuate wildly as other
applications come and go on the system.
In this proposal, we amend the memory.low control in memcg to protect a cgroup’s
memory usage in top-tier memory. A low protection for top-tier memory is scaled
proportionally to the ratio of top-tier memory and total memory on the system.
The protection is then applied to reclaim for top-tier memory. Promotion by NUMA
balancing is also throttled through reduced scanning window when top-tier memory
is contended and the cgroup is over its protection.
Experiments we did with microbenchmarks exhibiting a range of memory access
patterns and memory size confirmed that when top-tier memory is contended, the
system moves towards a stable memory distribution where each cgroup’s memory
usage in local DRAM converges to the protected amounts.
One notable missing part in the patches is determining which NUMA nodes have
top-tier memory; currently they use hardcoded node 0 for top-tier memory and
node 1 for a CPU-less node backed by CXL memory. We’re working on removing
this artifact and correctly applying to top-tier nodes in the system.
Your feedback is greatly appreciated!
Kaiyang Zhao (4):
Add get_cgroup_local_usage for estimating the top-tier memory usage
calculate memory.low for the local node and track its usage
use memory.low local node protection for local node reclaim
reduce NUMA balancing scan size of cgroups over their local memory.low
include/linux/memcontrol.h | 25 ++++++++-----
include/linux/page_counter.h | 16 ++++++---
kernel/sched/fair.c | 54 +++++++++++++++++++++++++---
mm/hugetlb_cgroup.c | 4 +--
mm/memcontrol.c | 68 ++++++++++++++++++++++++++++++------
mm/page_counter.c | 52 +++++++++++++++++++++------
mm/vmscan.c | 19 +++++++---
7 files changed, 192 insertions(+), 46 deletions(-)
--
2.43.0
next reply other threads:[~2024-09-20 22:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 22:11 kaiyang2 [this message]
2024-09-20 22:11 ` [RFC PATCH 1/4] Add get_cgroup_local_usage for estimating the top-tier memory usage kaiyang2
2024-09-20 22:11 ` [RFC PATCH 2/4] calculate memory.low for the local node and track its usage kaiyang2
2024-09-22 8:39 ` kernel test robot
2024-10-15 22:05 ` Gregory Price
2024-09-20 22:11 ` [RFC PATCH 3/4] use memory.low local node protection for local node reclaim kaiyang2
2024-10-15 21:52 ` Gregory Price
2024-09-20 22:11 ` [RFC PATCH 4/4] reduce NUMA balancing scan size of cgroups over their local memory.low kaiyang2
2024-11-08 19:01 ` [RFC PATCH 0/4] memory tiering fairness by per-cgroup control of promotion and demotion kaiyang2
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=20240920221202.1734227-1-kaiyang2@cs.cmu.edu \
--to=kaiyang2@cs.cmu.edu \
--cc=abhishekd@meta.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=nehagholkar@meta.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.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