linux-kernel - Re: [RFC][PATCH 0/8] Migrate Pages 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]

Message-ID: <654d785f-3fe5-d8bd-86bf-bf7431527184@intel.com>
Date:   Tue, 30 Jun 2020 11:51:32 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Shakeel Butt <shakeelb@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, Linux MM <linux-mm@...ck.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        David Rientjes <rientjes@...gle.com>,
        Huang Ying <ying.huang@...el.com>,
        Dan Williams <dan.j.williams@...el.com>
Subject: Re: [RFC][PATCH 0/8] Migrate Pages in lieu of discard

On 6/30/20 11:36 AM, Shakeel Butt wrote:
>> This is part of a larger patch set.  If you want to apply these or
>> play with them, I'd suggest using the tree from here.  It includes
>> autonuma-based hot page promotion back to DRAM:
>>
>>         http://lkml.kernel.org/r/c3d6de4d-f7c3-b505-2e64-8ee5f70b2118@intel.com
>>
>> This is also all based on an upstream mechanism that allows
>> persistent memory to be onlined and used as if it were volatile:
>>
>>         http://lkml.kernel.org/r/20190124231441.37A4A305@viggo.jf.intel.com
>>
> I have a high level question. Given a reclaim request for a set of
> nodes, if there is no demotion path out of that set, should the kernel
> still consider the migrations within the set of nodes? 

OK, to be specific, we're talking about a case where we've arrived at
try_to_free_pages() and, say, all of the nodes on the system are set in
sc->nodemask?  Isn't the common case that all nodes are set in
sc->nodemask?  Since there is never a demotion path out of the set of
all nodes, the common case would be that there is no demotion path out
of a reclaim node set.

If that's true, I'd say that the kernel still needs to consider
migrations even within the set.