From: Dan Williams <dan.j.williams@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
Michal Hocko <MHocko@suse.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"Huang, Ying" <ying.huang@intel.com>,
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 11:58:06 -0700 [thread overview]
Message-ID: <CAPcyv4jcgRTR-NnHPpsLm=z8uSLJZYN530nGm5f9k6Q3WGHr0g@mail.gmail.com> (raw)
In-Reply-To: <2677a7f9-5dc8-7590-2b8b-a67da1cb6b92@intel.com>
On Tue, Oct 23, 2018 at 11:17 AM Dave Hansen <dave.hansen@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)?
>
> Volatile.
>
> >> 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.
>
> Well, we do lots of things like stable device naming from udev scripts.
> We depend on them not being lost. At least this "fails safe" so we'll
> default to persistence instead of defaulting to "eat your data".
>
Right, and at least for the persistent memory to volatile conversion
case we will have the UUID to positively identify the DAX device. So
it will indeed "fail safe" and just become a dax_pmem device again if
the configuration is lost. We'll likely need to create/use a "by-path"
scheme for non-pmem use cases.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2018-10-23 18:58 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 [this message]
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='CAPcyv4jcgRTR-NnHPpsLm=z8uSLJZYN530nGm5f9k6Q3WGHr0g@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=MHocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@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: 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).