From: Dave Hansen <dave.hansen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Balbir Singh
<bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: thomas.lendacky-5C7GfCeVMHo@public.gmane.org,
mhocko-IBi9RG/b67k@public.gmane.org,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
tiwai-l3A5Bk7waGM@public.gmane.org,
zwisler-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/@public.gmane.org,
ying.huang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
bp-l3A5Bk7waGM@public.gmane.org
Subject: Re: [PATCH 0/5] [v4] Allow persistent memory to be used like normal RAM
Date: Mon, 28 Jan 2019 08:50:49 -0800 [thread overview]
Message-ID: <3ea28fe1-1828-1017-fa0f-da626d773440@intel.com> (raw)
In-Reply-To: <20190128110958.GH26056@350D>
On 1/28/19 3:09 AM, Balbir Singh wrote:
>> This is intended for Intel-style NVDIMMs (aka. Intel Optane DC
>> persistent memory) NVDIMMs. These DIMMs are physically persistent,
>> more akin to flash than traditional RAM. They are also expected to
>> be more cost-effective than using RAM, which is why folks want this
>> set in the first place.
> What variant of NVDIMM's F/P or both?
I'd expect this to get used in any cases where the NVDIMM is
cost-effective vs. DRAM. Today, I think that's only NVDIMM-P. At least
from what Wikipedia tells me about F vs. P vs. N:
https://en.wikipedia.org/wiki/NVDIMM
>> == Patch Set Overview ==
>>
>> 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.
>
> NUMA is distance based topology, does HMAT solve these problems?
NUMA is no longer just distance-based. Any memory with different
properties, like different memory-side caches or bandwidth properties
can be in its own, discrete NUMA node.
> How do we prevent fallback nodes of normal nodes being pmem nodes?
NUMA policies.
> On an unexpected crash/failure is there a scrubbing mechanism
> or do we rely on the allocator to do the right thing prior to
> reallocating any memory.
Yes, but this is not unique to persistent memory. On a kexec-based
crash, there might be old, sensitive data in *RAM* when the kernel comes
up. We depend on the allocator to zero things there. We also just
plain depend on the allocator to zero things so we don't leak
information when recycling pages in the first place.
I can't think of a scenario where some kind of "leak" of old data
wouldn't also be a bug with normal, volatile RAM.
> Will frequent zero'ing hurt NVDIMM/pmem's life times?
Everybody reputable that sells things with limited endurance quantifies
the endurance. I'd suggest that folks know what the endurance of their
media is before enabling this.
WARNING: multiple messages have this Message-ID
From: Dave Hansen <dave.hansen@intel.com>
To: Balbir Singh <bsingharora@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, thomas.lendacky@amd.com,
mhocko@suse.com, linux-nvdimm@lists.01.org, tiwai@suse.de,
ying.huang@intel.com, linux-mm@kvack.org, jglisse@redhat.com,
bp@suse.de, baiyaowei@cmss.chinamobile.com, zwisler@kernel.org,
bhelgaas@google.com, fengguang.wu@intel.com,
akpm@linux-foundation.org
Subject: Re: [PATCH 0/5] [v4] Allow persistent memory to be used like normal RAM
Date: Mon, 28 Jan 2019 08:50:49 -0800 [thread overview]
Message-ID: <3ea28fe1-1828-1017-fa0f-da626d773440@intel.com> (raw)
Message-ID: <20190128165049.IW-5r3bj0zyBizDwNO9nSByDBYYzsYabEM29L-JR0n8@z> (raw)
In-Reply-To: <20190128110958.GH26056@350D>
On 1/28/19 3:09 AM, Balbir Singh wrote:
>> This is intended for Intel-style NVDIMMs (aka. Intel Optane DC
>> persistent memory) NVDIMMs. These DIMMs are physically persistent,
>> more akin to flash than traditional RAM. They are also expected to
>> be more cost-effective than using RAM, which is why folks want this
>> set in the first place.
> What variant of NVDIMM's F/P or both?
I'd expect this to get used in any cases where the NVDIMM is
cost-effective vs. DRAM. Today, I think that's only NVDIMM-P. At least
from what Wikipedia tells me about F vs. P vs. N:
https://en.wikipedia.org/wiki/NVDIMM
>> == Patch Set Overview ==
>>
>> 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.
>
> NUMA is distance based topology, does HMAT solve these problems?
NUMA is no longer just distance-based. Any memory with different
properties, like different memory-side caches or bandwidth properties
can be in its own, discrete NUMA node.
> How do we prevent fallback nodes of normal nodes being pmem nodes?
NUMA policies.
> On an unexpected crash/failure is there a scrubbing mechanism
> or do we rely on the allocator to do the right thing prior to
> reallocating any memory.
Yes, but this is not unique to persistent memory. On a kexec-based
crash, there might be old, sensitive data in *RAM* when the kernel comes
up. We depend on the allocator to zero things there. We also just
plain depend on the allocator to zero things so we don't leak
information when recycling pages in the first place.
I can't think of a scenario where some kind of "leak" of old data
wouldn't also be a bug with normal, volatile RAM.
> Will frequent zero'ing hurt NVDIMM/pmem's life times?
Everybody reputable that sells things with limited endurance quantifies
the endurance. I'd suggest that folks know what the endurance of their
media is before enabling this.
next prev parent reply other threads:[~2019-01-28 16:50 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-24 23:14 Dave Hansen
2019-01-24 23:14 ` Dave Hansen
2019-01-24 23:14 ` [PATCH 1/5] mm/resource: return real error codes from walk failures Dave Hansen
2019-01-24 23:14 ` Dave Hansen
2019-01-25 21:02 ` Bjorn Helgaas
2019-01-25 21:02 ` Bjorn Helgaas
2019-01-25 21:09 ` Dave Hansen
2019-01-25 21:19 ` Bjorn Helgaas
2019-01-25 21:19 ` Bjorn Helgaas
2019-01-29 1:18 ` Michael Ellerman
2019-01-24 23:14 ` [PATCH 2/5] mm/resource: move HMM pr_debug() deeper into resource code Dave Hansen
2019-01-24 23:14 ` Dave Hansen
2019-01-25 19:07 ` Jerome Glisse
2019-01-25 21:18 ` Bjorn Helgaas
2019-01-25 21:18 ` Bjorn Helgaas
2019-01-25 21:24 ` Dave Hansen
2019-01-29 1:34 ` Michael Ellerman
2019-01-24 23:14 ` [PATCH 3/5] mm/memory-hotplug: allow memory resources to be children Dave Hansen
2019-01-24 23:14 ` Dave Hansen
2019-01-24 23:14 ` [PATCH 4/5] dax/kmem: let walk_system_ram_range() search child resources Dave Hansen
2019-01-24 23:14 ` Dave Hansen
2019-01-24 23:14 ` [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM Dave Hansen
2019-01-24 23:14 ` Dave Hansen
2019-01-25 6:13 ` Jane Chu
2019-01-25 6:27 ` Dan Williams
2019-01-25 6:27 ` Dan Williams
2019-01-25 8:20 ` Du, Fan
2019-01-25 17:18 ` Dan Williams
2019-01-25 18:20 ` Verma, Vishal L
2019-01-25 19:10 ` Jane Chu
2019-01-25 19:15 ` Dan Williams
2019-01-25 19:15 ` Dan Williams
2019-01-25 23:30 ` Jane Chu
2019-01-28 9:25 ` Michal Hocko
2019-01-28 16:34 ` Dan Williams
2019-01-28 16:34 ` Dan Williams
2019-02-09 11:00 ` Brice Goglin
2019-02-11 16:22 ` Dave Hansen
2019-02-12 19:59 ` Brice Goglin
2019-02-13 0:30 ` Dan Williams
2019-02-13 8:12 ` Brice Goglin
2019-02-13 8:24 ` Dan Williams
2019-02-13 8:43 ` Brice Goglin
2019-02-13 13:06 ` Brice Goglin
2019-02-13 16:19 ` Dan Williams
2019-01-25 19:08 ` [PATCH 0/5] [v4] Allow persistent memory to be used " Jerome Glisse
2019-01-28 11:09 ` Balbir Singh
2019-01-28 16:50 ` Dave Hansen [this message]
2019-01-28 16:50 ` Dave Hansen
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=3ea28fe1-1828-1017-fa0f-da626d773440@intel.com \
--to=dave.hansen-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=baiyaowei-0p4V/sDNsUmm0O/7XYngnFaTQe2KTcn/@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=bp-l3A5Bk7waGM@public.gmane.org \
--cc=bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=mhocko-IBi9RG/b67k@public.gmane.org \
--cc=thomas.lendacky-5C7GfCeVMHo@public.gmane.org \
--cc=tiwai-l3A5Bk7waGM@public.gmane.org \
--cc=ying.huang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=zwisler-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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