From: David Rientjes <rientjes@google.com>
To: Michal Hocko <mhocko@suse.com>, Dan Williams <dan.j.williams@intel.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
Wei Xu <weixugc@google.com>,
Frank van der Linden <fvdl@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Huang Ying <ying.huang@intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Yang Shi <shy828301@gmail.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Jon Grimm <jon.grimm@amd.com>
Subject: [LSF/MM/BPF TOPIC] The future of memory tiering
Date: Wed, 26 Apr 2023 21:30:54 -0700 (PDT) [thread overview]
Message-ID: <7443f0e6-6be2-3320-60d9-03da0cca2987@google.com> (raw)
Hi everybody,
As requested, sending along a last minute topic suggestion for
consideration for LSF/MM/BPF 2023 :)
For a sizable set of emerging technologies, memory tiering presents one of
the most formidable challenges and exicting opportunities for the MM
subsystem today.
"Memory tiering" can mean many different things based on the user: from
traditional every day NUMA, to swap (to zswap), to NVDIMMs, to HBM, to
locally attached CXL memory, to memory borrowing over PCIe, to memory
pooling with disaggregation, and beyond.
Just as NUMA started out only being useful for the supercomputers, memory
tiering will likely evolve over the next five years to take on an
expanding set of use cases, and likely with rapidly increasing adoption
even beyond hyperscalers.
I think a discussion about memory tiering would be highly valuable. A few
key questions that I think can drive this discussion:
- What are the various form factors that must be supported as short-term
goals as well as need to be supported 5+ years into the future?
- What incremental changes need to be made on top of NUMA support to
fully support the wide range of use cases that will be coming? (Is
memory tiering support built entirely upon NUMA?)
- What is the minimum viable *default* support that the MM subsystem
should provide for tiered configs? What are the set of optimizations
that should be left to userspace or BPF to control?
- What are the various page promotion technqiues that we must plan for
beyond traditional NUMA balancing that will allow us to exploit
hardware innovation?
(And I'm sure there are more topics of discussion that others would
readily add. It would be great to have additional ideas in replies.)
A key challenge in all of this is to make memory tiering support in the
upstream kernel compatible with the roadmaps of various CPU vendors. A
key goal is to ensure the end user benefits from all of this rapid
innovation with generalized support that is well abstracted and allows for
extensibility.
next reply other threads:[~2023-04-27 4:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 4:30 David Rientjes [this message]
2023-04-27 17:10 ` Frank van der Linden
2023-04-28 3:55 ` Wei Xu
2023-04-28 8:04 ` Huang, Ying
2023-04-29 2:26 ` Yang Shi
2023-05-01 13:16 ` Jason Gunthorpe
2023-05-01 19:21 ` John Hubbard
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=7443f0e6-6be2-3320-60d9-03da0cca2987@google.com \
--to=rientjes@google.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=fvdl@google.com \
--cc=hannes@cmpxchg.org \
--cc=jon.grimm@amd.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.com \
--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