From: Brice Goglin <brice.goglin@gmail.com>
To: Dave Hansen <dave.hansen@linux.intel.com>, linux-kernel@vger.kernel.org
Cc: dan.j.williams@intel.com, dave.jiang@intel.com,
zwisler@kernel.org, vishal.l.verma@intel.com,
thomas.lendacky@amd.com, akpm@linux-foundation.org,
mhocko@suse.com, linux-nvdimm@lists.01.org, linux-mm@kvack.org,
ying.huang@intel.com, fengguang.wu@intel.com
Subject: Re: [PATCH 0/9] Allow persistent memory to be used like normal RAM
Date: Mon, 3 Dec 2018 10:22:24 +0100 [thread overview]
Message-ID: <ffeb6225-6d5c-099e-3158-4711c879ec23@gmail.com> (raw)
In-Reply-To: <20181022201317.8558C1D8@viggo.jf.intel.com>
Le 22/10/2018 à 22:13, Dave Hansen a écrit :
> Persistent memory is cool. But, currently, you have to rewrite
> your applications to use it. Wouldn't it be cool if you could
> just have it show up in your system like normal RAM and get to
> it like a slow blob of memory? Well... have I got the patch
> series for you!
>
> This series adds a new "driver" to which pmem devices can be
> attached. Once attached, the memory "owned" by the device is
> hot-added to the kernel and managed like any other memory. On
> systems with an HMAT (a new ACPI table), each socket (roughly)
> will have a separate NUMA node for its persistent memory so
> this newly-added memory can be selected by its unique NUMA
> node.
Hello Dave
What happens on systems without an HMAT? Does this new memory get merged
into existing NUMA nodes?
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?
Brice
next prev parent reply other threads:[~2018-12-03 9:22 UTC|newest]
Thread overview: 49+ 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 ` 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 ` Dave Hansen
2018-10-22 20:13 ` [PATCH 2/9] dax: kernel memory driver for mm ownership of DAX Dave Hansen
2018-10-22 20:13 ` Dave Hansen
2018-10-23 1:56 ` Randy Dunlap
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 ` 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 ` 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 ` 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 ` Dave Hansen
2018-10-22 20:13 ` [PATCH 7/9] dax/kmem: actually perform memory hotplug Dave Hansen
2018-10-22 20:13 ` 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 ` Dave Hansen
2018-10-22 20:13 ` [PATCH 9/9] dax/kmem: actually enable the code in Makefile Dave Hansen
2018-10-22 20:13 ` 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-23 1:11 ` Dan Williams
2018-10-26 8:03 ` Xishi Qiu
2018-10-26 13:58 ` Dave Hansen
2018-10-26 13:58 ` Dave Hansen
2018-10-27 4:45 ` Dan Williams
2018-10-27 4:45 ` Dan Williams
2018-10-23 18:12 ` Elliott, Robert (Persistent Memory)
2018-10-23 18:12 ` Elliott, Robert (Persistent Memory)
2018-10-23 18:16 ` Dave Hansen
2018-10-23 18:16 ` Dave Hansen
2018-10-23 18:58 ` Dan Williams
2018-10-23 18:58 ` Dan Williams
2018-10-26 5:42 ` Xishi Qiu
2018-10-26 5:42 ` Xishi Qiu
2018-10-26 9:03 ` Fengguang Wu
2018-10-26 9:03 ` Fengguang Wu
2018-10-27 11:00 ` Fengguang Wu
2018-10-27 11:00 ` Fengguang Wu
2018-10-31 5:11 ` Yang Shi
2018-10-31 5:11 ` Yang Shi
2018-12-03 9:22 ` Brice Goglin [this message]
2018-12-03 16:56 ` Dave Hansen
2018-12-03 16:56 ` Dave Hansen
2018-12-03 17:16 ` Dan Williams
2018-12-03 17:16 ` Dan Williams
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=ffeb6225-6d5c-099e-3158-4711c879ec23@gmail.com \
--to=brice.goglin@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=fengguang.wu@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.