linux-kernel - Re: [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of discard

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]

Date:   Wed, 1 Jul 2020 11:20:00 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Huang, Ying" <ying.huang@...el.com>,
        David Rientjes <rientjes@...gle.com>
Cc:     Yang Shi <yang.shi@...ux.alibaba.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        kbusch@...nel.org, dan.j.williams@...el.com
Subject: Re: [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of
 discard

On 7/1/20 1:54 AM, Huang, Ying wrote:
> Why can not we just bind the memory of the application to node 0, 2, 3
> via mbind() or cpuset.mems?  Then the application can allocate memory
> directly from PMEM.  And if we bind the memory of the application via
> mbind() to node 0, we can only allocate memory directly from DRAM.

Applications use cpuset.mems precisely because they don't want to
allocate directly from PMEM.  They want the good, deterministic,
performance they get from DRAM.

Even if they don't allocate directly from PMEM, is it OK for such an app
to get its cold data migrated to PMEM?  That's a much more subtle
question and I suspect the kernel isn't going to have a single answer
for it.  I suspect we'll need a cpuset-level knob to turn auto-demotion
on or off.