[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2dee13d-a19a-2b53-7317-7227749375d9@intel.com>
Date: Mon, 23 Oct 2017 15:10:05 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
Michal Nazarewicz <mina86@...a86.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Guy Shattah <sguy@...lanox.com>,
Christoph Lameter <cl@...ux.com>
Subject: Re: [RFC] mmap(MAP_CONTIG)
On 10/03/2017 04:56 PM, Mike Kravetz wrote:
> mmap(MAP_CONTIG) would have the following semantics:
> - The entire mapping (length size) would be backed by physically contiguous
> pages.
> - If 'length' physically contiguous pages can not be allocated, then mmap
> will fail.
> - MAP_CONTIG only works with MAP_ANONYMOUS mappings.
> - MAP_CONTIG will lock the associated pages in memory. As such, the same
> privileges and limits that apply to mlock will also apply to MAP_CONTIG.
> - A MAP_CONTIG mapping can not be expanded.
Do you also need to lock out the NUMA migration APIs somehow? What
about KSM (or does it already ignore VM_LOCKED)?
> - At fork time, private MAP_CONTIG mappings will be converted to regular
> (non-MAP_CONTIG) mapping in the child. As such a COW fault in the child
> will not require a contiguous allocation.
Maybe we should just define it as acting as if it had MADV_DONTFORK set
on it, and also that it doesn't allow MADV_DONTFORK to be called on it.
Powered by blists - more mailing lists