linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"Verma, Vishal L" <vishal.l.verma@intel.com>,
	Wu Fengguang <fengguang.wu@intel.com>,
	Huang Ying <ying.huang@intel.com>
Subject: [RFC] Memory Tiering
Date: Wed, 16 Oct 2019 13:05:46 -0700	[thread overview]
Message-ID: <c3d6de4d-f7c3-b505-2e64-8ee5f70b2118@intel.com> (raw)

The memory hierarchy is getting more complicated and the kernel is
playing an increasing role in managing the different tiers.  A few
different groups of folks described "migration" optimizations they were
doing in this area at LSF/MM earlier this year.  One of the questions
folks asked was why autonuma wasn't being used.

At Intel, the primary new tier that we're looking at is persistent
memory (PMEM).  We'd like to be able to use "persistent memory"
*without* using its persistence properties, treating it as slightly
slower DRAM.  Keith Busch has some patches to use NUMA migration to
automatically migrate DRAM->PMEM instead of discarding it near the end
of the reclaim process.  Huang Ying has some patches which use a
modified autonuma to migrate frequently-used data *back* from PMEM->DRAM.

We've tried to do this all generically so that it is not tied to
persistent memory and can be applied to any memory types in lots of
topologies.

We've been running this code in various forms for the past few months,
comparing it to pure DRAM and hardware-based caching.  The initial
results are encouraging and we thought others might want to take a look
at the code or run their own experiments.  We're expecting to post the
individual patches soon.  But, until then, the code is available here:

 	https://git.kernel.org/pub/scm/linux/kernel/git/vishal/tiering.git

and is tagged with "tiering-0.2", aka. d8e31e81b1dca9.

Note that internally folks have been calling this "hmem" which is
terribly easy to confuse with the existing hmm.  There are still some
"hmem"'s in the tree, but I don't expect them to live much longer.


             reply	other threads:[~2019-10-16 20:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 20:05 Dave Hansen [this message]
2019-10-17  8:07 ` [RFC] Memory Tiering David Hildenbrand
2019-10-17 14:17   ` Dave Hansen
2019-10-17 17:07     ` Verma, Vishal L
2019-10-17 17:34       ` David Hildenbrand
2019-10-23 23:11 ` Jonathan Adams
2019-10-24 16:33   ` Dave Hansen
2019-10-25  3:30     ` Huang, Ying
2019-10-24 17:06   ` Yang Shi
2019-10-25  3:40   ` Huang, Ying

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=c3d6de4d-f7c3-b505-2e64-8ee5f70b2118@intel.com \
    --to=dave.hansen@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vishal.l.verma@intel.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).