linux-kernel - Re: [RFC 0/8] Define coherent device memory node

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:   Mon, 24 Oct 2016 13:32:09 -0500
From:   David Nellans <dnellans@...dia.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>
CC:     <mhocko@...e.com>, <js1304@...il.com>, <vbabka@...e.cz>,
        <mgorman@...e.de>, <minchan@...nel.org>,
        <akpm@...ux-foundation.org>, <aneesh.kumar@...ux.vnet.ibm.com>,
        <bsingharora@...il.com>
Subject: Re: [RFC 0/8] Define coherent device memory node

On 10/24/2016 01:04 PM, Dave Hansen wrote:

> On 10/23/2016 09:31 PM, Anshuman Khandual wrote:
>> 	To achieve seamless integration  between system RAM and coherent
>> device memory it must be able to utilize core memory kernel features like
>> anon mapping, file mapping, page cache, driver managed pages, HW poisoning,
>> migrations, reclaim, compaction, etc.
> So, you need to support all these things, but not autonuma or hugetlbfs?
>   What's the reasoning behind that?
>
> If you *really* don't want a "cdm" page to be migrated, then why isn't
> that policy set on the VMA in the first place?  That would keep "cdm"
> pages from being made non-cdm.  And, why would autonuma ever make a
> non-cdm page and migrate it in to cdm?  There will be no NUMA access
> faults caused by the devices that are fed to autonuma.
>
Pages are desired to be migrateable, both into (starting cpu zone 
movable->cdm) and out of (starting cdm->cpu zone movable) but only 
through explicit migration, not via autonuma.  other pages in the same 
VMA should still be migrateable between CPU nodes via autonuma however.

Its expected a lot of these allocations are going to end up in THPs.  
I'm not sure we need to explicitly disallow hugetlbfs support but the 
identified use case is definitely via THPs not tlbfs.