From: "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> To: 'Dan Williams' <dan.j.williams@intel.com>, Dave Hansen <dave.hansen@linux.intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com>, "Hocko, Michal" <MHocko@suse.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, "zwisler@kernel.org" <zwisler@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux MM <linux-mm@kvack.org>, "Huang, Ying" <ying.huang@intel.com>, Andrew Morton <akpm@linux-foundation.org>, Fengguang Wu <fengguang.wu@intel.com> Subject: RE: [PATCH 0/9] Allow persistent memory to be used like normal RAM Date: Tue, 23 Oct 2018 18:12:11 +0000 [thread overview] Message-ID: <AT5PR8401MB11694012893ED2121D7A345EABF50@AT5PR8401MB1169.NAMPRD84.PROD.OUTLOOK.COM> (raw) In-Reply-To: <CAPcyv4hxs-GnmwQU1wPZyg5aydCY5K09-YpSrrLpvU1v_8dbBw@mail.gmail.com> > -----Original Message----- > From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of Dan Williams > Sent: Monday, October 22, 2018 8:05 PM > Subject: Re: [PATCH 0/9] Allow persistent memory to be used like normal RAM > > On Mon, Oct 22, 2018 at 1:18 PM Dave Hansen <dave.hansen@linux.intel.com> wrote: ... > 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 Would this memory be considered volatile (with the driver initializing it to zeros), or persistent (contents are presented unchanged, applications may guarantee persistence by using cache flush instructions, fence instructions, and writing to flush hint addresses per the persistent memory programming model)? > > 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. ... > 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. Where would that rule be stored? Storing it on another device is problematic. If that rule is lost, it could confuse other drivers trying to grab device DAX devices for use as persistent memory. A new namespace mode would record the intended usage in the device itself, eliminating dependencies. It could join the other modes like: ndctl create-namespace -m raw create /dev/pmem4 block device ndctl create-namespace -m sector create /dev/pmem4s block device ndctl create-namespace -m fsdax create /dev/pmem4 block device ndctl create-namespace -m devdax create /dev/dax4.3 character device for use as persistent memory ndctl create-namespace -m mem create /dev/mem4.3 character device for use as volatile memory --- Robert Elliott, HPE Persistent Memory _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> To: 'Dan Williams' <dan.j.williams@intel.com>, Dave Hansen <dave.hansen@linux.intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com>, "Hocko, Michal" <MHocko@suse.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, "Huang, Ying" <ying.huang@intel.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux MM <linux-mm@kvack.org>, "zwisler@kernel.org" <zwisler@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Fengguang Wu <fengguang.wu@intel.com> Subject: RE: [PATCH 0/9] Allow persistent memory to be used like normal RAM Date: Tue, 23 Oct 2018 18:12:11 +0000 [thread overview] Message-ID: <AT5PR8401MB11694012893ED2121D7A345EABF50@AT5PR8401MB1169.NAMPRD84.PROD.OUTLOOK.COM> (raw) In-Reply-To: <CAPcyv4hxs-GnmwQU1wPZyg5aydCY5K09-YpSrrLpvU1v_8dbBw@mail.gmail.com> > -----Original Message----- > From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of Dan Williams > Sent: Monday, October 22, 2018 8:05 PM > Subject: Re: [PATCH 0/9] Allow persistent memory to be used like normal RAM > > On Mon, Oct 22, 2018 at 1:18 PM Dave Hansen <dave.hansen@linux.intel.com> wrote: ... > 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 Would this memory be considered volatile (with the driver initializing it to zeros), or persistent (contents are presented unchanged, applications may guarantee persistence by using cache flush instructions, fence instructions, and writing to flush hint addresses per the persistent memory programming model)? > > 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. ... > 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. Where would that rule be stored? Storing it on another device is problematic. If that rule is lost, it could confuse other drivers trying to grab device DAX devices for use as persistent memory. A new namespace mode would record the intended usage in the device itself, eliminating dependencies. It could join the other modes like: ndctl create-namespace -m raw create /dev/pmem4 block device ndctl create-namespace -m sector create /dev/pmem4s block device ndctl create-namespace -m fsdax create /dev/pmem4 block device ndctl create-namespace -m devdax create /dev/dax4.3 character device for use as persistent memory ndctl create-namespace -m mem create /dev/mem4.3 character device for use as volatile memory --- Robert Elliott, HPE Persistent Memory
next prev parent reply other threads:[~2018-10-23 18:12 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) [this message] 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 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=AT5PR8401MB11694012893ED2121D7A345EABF50@AT5PR8401MB1169.NAMPRD84.PROD.OUTLOOK.COM \ --to=elliott@hpe.com \ --cc=MHocko@suse.com \ --cc=akpm@linux-foundation.org \ --cc=dan.j.williams@intel.com \ --cc=dave.hansen@linux.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=thomas.lendacky@amd.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: linkBe 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.