From: Dan Williams <dan.j.williams@intel.com>
To: "Du, Fan" <fan.du@intel.com>
Cc: Michal Hocko <mhocko@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Wu, Fengguang" <fengguang.wu@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"xishi.qiuxishi@alibaba-inc.com"
<xishi.qiuxishi@alibaba-inc.com>,
"Huang, Ying" <ying.huang@intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/5] New fallback workflow for heterogeneous memory system
Date: Thu, 25 Apr 2019 08:43:08 -0700 [thread overview]
Message-ID: <CAPcyv4jpiPg+dbFg0BrNSqGjxKA6CQdBiLp5L=nrLWzN7mD8Kw@mail.gmail.com> (raw)
In-Reply-To: <5A90DA2E42F8AE43BC4A093BF067884825785F6E@SHSMSX104.ccr.corp.intel.com>
On Thu, Apr 25, 2019 at 1:05 AM Du, Fan <fan.du@intel.com> wrote:
>
>
>
> >-----Original Message-----
> >From: owner-linux-mm@kvack.org [mailto:owner-linux-mm@kvack.org] On
> >Behalf Of Michal Hocko
> >Sent: Thursday, April 25, 2019 3:54 PM
> >To: Du, Fan <fan.du@intel.com>
> >Cc: akpm@linux-foundation.org; Wu, Fengguang <fengguang.wu@intel.com>;
> >Williams, Dan J <dan.j.williams@intel.com>; Hansen, Dave
> ><dave.hansen@intel.com>; xishi.qiuxishi@alibaba-inc.com; Huang, Ying
> ><ying.huang@intel.com>; linux-mm@kvack.org; linux-kernel@vger.kernel.org
> >Subject: Re: [RFC PATCH 0/5] New fallback workflow for heterogeneous
> >memory system
> >
> >On Thu 25-04-19 07:41:40, Du, Fan wrote:
> >>
> >>
> >> >-----Original Message-----
> >> >From: Michal Hocko [mailto:mhocko@kernel.org]
> >> >Sent: Thursday, April 25, 2019 2:37 PM
> >> >To: Du, Fan <fan.du@intel.com>
> >> >Cc: akpm@linux-foundation.org; Wu, Fengguang
> ><fengguang.wu@intel.com>;
> >> >Williams, Dan J <dan.j.williams@intel.com>; Hansen, Dave
> >> ><dave.hansen@intel.com>; xishi.qiuxishi@alibaba-inc.com; Huang, Ying
> >> ><ying.huang@intel.com>; linux-mm@kvack.org;
> >linux-kernel@vger.kernel.org
> >> >Subject: Re: [RFC PATCH 0/5] New fallback workflow for heterogeneous
> >> >memory system
> >> >
> >> >On Thu 25-04-19 09:21:30, Fan Du wrote:
> >> >[...]
> >> >> However PMEM has different characteristics from DRAM,
> >> >> the more reasonable or desirable fallback style would be:
> >> >> DRAM node 0 -> DRAM node 1 -> PMEM node 2 -> PMEM node 3.
> >> >> When DRAM is exhausted, try PMEM then.
> >> >
> >> >Why and who does care? NUMA is fundamentally about memory nodes
> >with
> >> >different access characteristics so why is PMEM any special?
> >>
> >> Michal, thanks for your comments!
> >>
> >> The "different" lies in the local or remote access, usually the underlying
> >> memory is the same type, i.e. DRAM.
> >>
> >> By "special", PMEM is usually in gigantic capacity than DRAM per dimm,
> >> while with different read/write access latency than DRAM.
> >
> >You are describing a NUMA in general here. Yes access to different NUMA
> >nodes has a different read/write latency. But that doesn't make PMEM
> >really special from a regular DRAM.
>
> Not the numa distance b/w cpu and PMEM node make PMEM different than
> DRAM. The difference lies in the physical layer. The access latency characteristics
> comes from media level.
No, there is no such thing as a "PMEM node". I've pushed back on this
broken concept in the past [1] [2]. Consider that PMEM could be as
fast as DRAM for technologies like NVDIMM-N or in emulation
environments. These attempts to look at persistence as an attribute of
performance are entirely missing the point that the system can have
multiple varied memory types and the platform firmware needs to
enumerate these performance properties in the HMAT on ACPI platforms.
Any scheme that only considers a binary DRAM and not-DRAM property is
immediately invalidated the moment the OS needs to consider a 3rd or
4th memory type, or a more varied connection topology.
[1]: https://lore.kernel.org/lkml/CAPcyv4heiUbZvP7Ewoy-Hy=-mPrdjCjEuSw+0rwdOUHdjwetxg@mail.gmail.com/
[2]: https://lore.kernel.org/lkml/CAPcyv4it1w7SdDVBV24cRCVHtLb3s1pVB5+SDM02Uw4RbahKiA@mail.gmail.com/
next prev parent reply other threads:[~2019-04-25 15:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 1:21 Fan Du
2019-04-25 1:21 ` [RFC PATCH 1/5] acpi/numa: memorize NUMA node type from SRAT table Fan Du
2019-04-25 1:21 ` [RFC PATCH 2/5] mmzone: new pgdat flags for DRAM and PMEM Fan Du
2019-04-25 1:21 ` [RFC PATCH 3/5] x86,numa: update numa node type Fan Du
2019-04-25 1:21 ` [RFC PATCH 4/5] mm, page alloc: build fallback list on per node type basis Fan Du
2019-04-25 1:21 ` [RFC PATCH 5/5] mm, page_alloc: Introduce ZONELIST_FALLBACK_SAME_TYPE fallback list Fan Du
[not found] ` <a0728518-a067-4f89-a8ae-3fa279f768f2.xishi.qiuxishi@alibaba-inc.com>
2019-04-25 3:26 ` Xishi Qiu
2019-04-25 7:45 ` Du, Fan
2019-04-25 6:38 ` Michal Hocko
2019-04-25 7:43 ` Du, Fan
2019-04-25 7:48 ` Michal Hocko
2019-04-25 7:55 ` Du, Fan
2019-04-25 8:09 ` Michal Hocko
2019-04-25 8:20 ` Du, Fan
2019-04-25 8:43 ` Michal Hocko
2019-04-25 9:18 ` Du, Fan
2019-04-25 6:37 ` [RFC PATCH 0/5] New fallback workflow for heterogeneous memory system Michal Hocko
2019-04-25 7:41 ` Du, Fan
2019-04-25 7:53 ` Michal Hocko
2019-04-25 8:05 ` Du, Fan
2019-04-25 15:43 ` Dan Williams [this message]
2019-04-26 2:40 ` Du, Fan
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='CAPcyv4jpiPg+dbFg0BrNSqGjxKA6CQdBiLp5L=nrLWzN7mD8Kw@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=fan.du@intel.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=xishi.qiuxishi@alibaba-inc.com \
--cc=ying.huang@intel.com \
/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