From: Dan Williams <dan.j.williams@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Brice Goglin <brice.goglin@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
zwisler@kernel.org, Vishal L Verma <vishal.l.verma@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Linux MM <linux-mm@kvack.org>,
"Huang, Ying" <ying.huang@intel.com>,
Fengguang Wu <fengguang.wu@intel.com>,
Keith Busch <keith.busch@intel.com>
Subject: Re: [PATCH 0/9] Allow persistent memory to be used like normal RAM
Date: Mon, 3 Dec 2018 09:16:01 -0800 [thread overview]
Message-ID: <CAPcyv4jU1A93J4pqme3bGHE_KJE2TZ_F9pncgesuksT8YaR-FQ@mail.gmail.com> (raw)
In-Reply-To: <48d78370-438d-65fa-370c-4cf61a27ed3d@intel.com>
On Mon, Dec 3, 2018 at 8:56 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 12/3/18 1:22 AM, Brice Goglin wrote:
> > Le 22/10/2018 à 22:13, Dave Hansen a écrit :
> > What happens on systems without an HMAT? Does this new memory get merged
> > into existing NUMA nodes?
>
> It gets merged into the persistent memory device's node, as told by the
> firmware. Intel's persistent memory should always be in its own node,
> separate from DRAM.
>
> > Also, do you plan to have a way for applications to find out which NUMA
> > nodes are "real DRAM" while others are "pmem-backed"? (something like a
> > new attribute in /sys/devices/system/node/nodeX/) Or should we use HMAT
> > performance attributes for this?
>
> The best way is to use the sysfs-generic interfaces to the HMAT that
> Keith Busch is pushing. In the end, we really think folks will only
> care about the memory's performance properties rather than whether it's
> *actually* persistent memory or not.
It's also important to point out that "persistent memory" by itself is
an ambiguous memory type. It's anything from new media with distinct
performance characteristics to battery backed DRAM. I.e. the
performance of "persistent memory" may be indistinguishable from "real
DRAM".
prev parent reply other threads:[~2018-12-03 17:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 20:13 [PATCH 0/9] Allow persistent memory to be used like normal RAM Dave Hansen
2018-10-22 20:13 ` [PATCH 1/9] mm/resource: return real error codes from walk failures Dave Hansen
2018-10-22 20:13 ` [PATCH 2/9] dax: kernel memory driver for mm ownership of DAX Dave Hansen
2018-10-23 1:56 ` Randy Dunlap
2018-10-22 20:13 ` [PATCH 3/9] dax: add more kmem device infrastructure Dave Hansen
2018-10-22 20:13 ` [PATCH 4/9] dax/kmem: allow PMEM devices to bind to KMEM driver Dave Hansen
2018-10-22 20:13 ` [PATCH 5/9] dax/kmem: add more nd dax kmem infrastructure Dave Hansen
2018-10-22 20:13 ` [PATCH 6/9] mm/memory-hotplug: allow memory resources to be children Dave Hansen
2018-10-22 20:13 ` [PATCH 7/9] dax/kmem: actually perform memory hotplug Dave Hansen
2018-10-22 20:13 ` [PATCH 8/9] dax/kmem: let walk_system_ram_range() search child resources Dave Hansen
2018-10-22 20:13 ` [PATCH 9/9] dax/kmem: actually enable the code in Makefile Dave Hansen
2018-10-23 1:05 ` [PATCH 0/9] Allow persistent memory to be used like normal RAM Dan Williams
2018-10-23 1:11 ` Dan Williams
2018-10-26 8:03 ` Xishi Qiu
2018-10-26 13:58 ` Dave Hansen
2018-10-27 4:45 ` Dan Williams
2018-10-23 18:12 ` Elliott, Robert (Persistent Memory)
2018-10-23 18:16 ` Dave Hansen
2018-10-23 18:58 ` Dan Williams
2018-10-26 5:42 ` Xishi Qiu
2018-10-26 9:03 ` Fengguang Wu
2018-10-27 11:00 ` Fengguang Wu
2018-10-31 5:11 ` Yang Shi
2018-12-03 9:22 ` Brice Goglin
2018-12-03 16:56 ` Dave Hansen
2018-12-03 17:16 ` Dan Williams [this message]
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=CAPcyv4jU1A93J4pqme3bGHE_KJE2TZ_F9pncgesuksT8YaR-FQ@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=brice.goglin@gmail.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=fengguang.wu@intel.com \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mhocko@suse.com \
--cc=thomas.lendacky@amd.com \
--cc=vishal.l.verma@intel.com \
--cc=ying.huang@intel.com \
--cc=zwisler@kernel.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).