From: Keith Busch <keith.busch@intel.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-nvdimm@lists.01.org
Cc: Dave Hansen <dave.hansen@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Keith Busch <keith.busch@intel.com>
Subject: [PATCH 0/5] Page demotion for memory reclaim
Date: Thu, 21 Mar 2019 14:01:52 -0600 [thread overview]
Message-ID: <20190321200157.29678-1-keith.busch@intel.com> (raw)
The kernel has recently added support for using persistent memory as
normal RAM:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c221c0b0308fd01d9fb33a16f64d2fd95f8830a4
The persistent memory is hot added to nodes separate from other memory
types, which makes it convenient to make node based memory policies.
When persistent memory provides a larger and cheaper address space, but
with slower access characteristics than system RAM, we'd like the kernel
to make use of these memory-only nodes as a migration tier for pages
that would normally be discared during memory reclaim. This is faster
than doing IO for swap or page cache, and makes better utilization of
available physical address space.
The feature is not enabled by default. The user must opt-in to kernel
managed page migration by defining the demotion path. In the future,
we may want to have the kernel automatically create this based on
heterogeneous memory attributes and CPU locality.
Keith Busch (5):
node: Define and export memory migration path
mm: Split handling old page for migration
mm: Attempt to migrate page in lieu of discard
mm: Consider anonymous pages without swap
mm/migrate: Add page movement trace event
Documentation/ABI/stable/sysfs-devices-node | 11 +-
drivers/base/node.c | 73 +++++++++++++
include/linux/migrate.h | 6 ++
include/linux/node.h | 6 ++
include/linux/swap.h | 20 ++++
include/trace/events/migrate.h | 29 ++++-
mm/debug.c | 1 +
mm/migrate.c | 161 ++++++++++++++++++----------
mm/vmscan.c | 25 ++++-
9 files changed, 271 insertions(+), 61 deletions(-)
--
2.14.4
next reply other threads:[~2019-03-21 20:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 20:01 Keith Busch [this message]
2019-03-21 20:01 ` [PATCH 1/5] node: Define and export memory migration path Keith Busch
2019-03-21 20:01 ` [PATCH 2/5] mm: Split handling old page for migration Keith Busch
2019-03-21 20:01 ` [PATCH 3/5] mm: Attempt to migrate page in lieu of discard Keith Busch
2019-03-21 23:58 ` Yang Shi
2019-03-22 16:34 ` Keith Busch
2019-03-21 20:01 ` [PATCH 4/5] mm: Consider anonymous pages without swap Keith Busch
2019-03-21 20:01 ` [PATCH 5/5] mm/migrate: Add page movement trace event Keith Busch
2019-03-21 21:20 ` [PATCH 0/5] Page demotion for memory reclaim Zi Yan
2019-03-21 22:37 ` Keith Busch
2019-03-21 23:02 ` Yang Shi
2019-03-22 0:20 ` Zi Yan
2019-03-22 0:12 ` Zi Yan
2019-03-22 14:41 ` Keith Busch
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=20190321200157.29678-1-keith.busch@intel.com \
--to=keith.busch@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
/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).