Re: [RFC] mmap(MAP_CONTIG)

[Mike Kravetz]

On 10/23/2017 03:10 PM, Dave Hansen wrote:
> 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)?

Yes, and no.
The primary use case driving this request is RDMA.  As such, the pages
can not move while being used for this purpose.

When this thread was started the thought was that generic mmap would
handle the contiguous allocations.  The resulting allocated pages would
be handed to the driver for additional setup based on it's specific needs.
Since then, the thought is that the driver should handle contiguous
allocations as well.  I am looking at making the existing contiguous memory
allocator more usable for driver writers.

-- 
Mike Kravetz

> 
>> - 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.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>