From: Dan Williams <dan.j.williams@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: 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>
Subject: Re: [PATCH 0/9] Allow persistent memory to be used like normal RAM
Date: Mon, 22 Oct 2018 18:05:11 -0700 [thread overview]
Message-ID: <CAPcyv4hxs-GnmwQU1wPZyg5aydCY5K09-YpSrrLpvU1v_8dbBw@mail.gmail.com> (raw)
In-Reply-To: <20181022201317.8558C1D8@viggo.jf.intel.com>
On Mon, Oct 22, 2018 at 1:18 PM Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
> 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.
>
> This is highly RFC, and I really want the feedback from the
> nvdimm/pmem folks about whether this is a viable long-term
> perversion of their code and device mode. It's insufficiently
> documented and probably not bisectable either.
>
> Todo:
> 1. The device re-binding hacks are ham-fisted at best. We
> need a better way of doing this, especially so the kmem
> driver does not get in the way of normal pmem devices.
> 2. When the device has no proper node, we default it to
> NUMA node 0. Is that OK?
> 3. We muck with the 'struct resource' code quite a bit. It
> definitely needs a once-over from folks more familiar
> with it than I.
> 4. Is there a better way to do this than starting with a
> copy of pmem.c?
So I don't think we want to do patch 2, 3, or 5. Just jump to patch 7
and remove all the devm_memremap_pages() infrastructure and dax_region
infrastructure.
The driver should be a dead simple turn around to call add_memory()
for the passed in range. The hard part is, as you say, arranging for
the kmem driver to not stand in the way of typical range / device
claims by the dax_pmem device.
To me this looks like teaching the nvdimm-bus and this dax_kmem driver
to require explicit matching based on 'id'. The attachment scheme
would look like this:
modprobe dax_kmem
echo dax0.0 > /sys/bus/nd/drivers/dax_kmem/new_id
echo dax0.0 > /sys/bus/nd/drivers/dax_pmem/unbind
echo dax0.0 > /sys/bus/nd/drivers/dax_kmem/bind
At step1 the dax_kmem drivers will match no devices and stays out of
the way of dax_pmem. It learns about devices it cares about by being
explicitly told about them. Then unbind from the typical dax_pmem
driver and attach to dax_kmem to perform the one way hotplug.
I expect udev can automate this by setting up a rule to watch for
device-dax instances by UUID and call a script to do the detach /
reattach dance.
next prev parent reply other threads:[~2018-10-23 1:05 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 ` Dan Williams [this message]
2018-10-23 1:11 ` [PATCH 0/9] Allow persistent memory to be used like normal RAM 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
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=CAPcyv4hxs-GnmwQU1wPZyg5aydCY5K09-YpSrrLpvU1v_8dbBw@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--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 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).