linux-kernel - RE: [RFC PATCH 0/5] New fallback workflow for heterogeneous memory system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5A90DA2E42F8AE43BC4A093BF067884825785EE8@SHSMSX104.ccr.corp.intel.com>
Date:   Thu, 25 Apr 2019 07:41:40 +0000
From:   "Du, Fan" <fan.du@...el.com>
To:     Michal Hocko <mhocko@...nel.org>
CC:     "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "Wu, Fengguang" <fengguang.wu@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "xishi.qiuxishi@...baba-inc.com" <xishi.qiuxishi@...baba-inc.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Du, Fan" <fan.du@...el.com>
Subject: RE: [RFC PATCH 0/5] New fallback workflow for heterogeneous memory
 system



>-----Original Message-----
>From: Michal Hocko [mailto:mhocko@...nel.org]
>Sent: Thursday, April 25, 2019 2:37 PM
>To: Du, Fan <fan.du@...el.com>
>Cc: akpm@...ux-foundation.org; Wu, Fengguang <fengguang.wu@...el.com>;
>Williams, Dan J <dan.j.williams@...el.com>; Hansen, Dave
><dave.hansen@...el.com>; xishi.qiuxishi@...baba-inc.com; Huang, Ying
><ying.huang@...el.com>; linux-mm@...ck.org; linux-kernel@...r.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. Iow PMEM
sits right under DRAM in the memory tier hierarchy.

This makes PMEM to be far memory, or second class memory.
So we give first class DRAM page to user, fallback to PMEM when
necessary.

The Cloud Service Provider can use DRAM + PMEM in their system,
Leveraging method [1] to keep hot page in DRAM and warm or cold
Page in PMEM, achieve optimal performance and reduce total cost
of ownership at the same time.

[1]:
https://github.com/fengguang/memory-optimizer

>--
>Michal Hocko
>SUSE Labs