Message-ID: <aff6b405-6a06-f84d-c9b1-c6fb166dff81@oracle.com>
Date:   Mon, 16 Oct 2017 10:43:38 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Guy Shattah <sguy@...lanox.com>, Michal Hocko <mhocko@...nel.org>,
        Christopher Lameter <cl@...ux.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org,
        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>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        Laura Abbott <labbott@...hat.com>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support

On 10/15/2017 12:50 AM, Guy Shattah wrote:
> On 13/10/2017 19:17, Michal Hocko wrote:
>> On Fri 13-10-17 10:56:13, Cristopher Lameter wrote:
>>> On Fri, 13 Oct 2017, Michal Hocko wrote:
>>>
>>>>> There is a generic posix interface that could we used for a variety of
>>>>> specific hardware dependent use cases.
>>>> Yes you wrote that already and my counter argument was that this generic
>>>> posix interface shouldn't bypass virtual memory abstraction.
>>> It does do that? In what way?
>> availability of the virtual address space depends on the availability of
>> the same sized contiguous physical memory range. That sounds like the
>> abstraction is gone to large part to me.
> In what way? userspace users will still be working with virtual memory.
> 
>>
>>>>> There are numerous RDMA devices that would all need the mmap
>>>>> implementation. And this covers only the needs of one subsystem. There are
>>>>> other use cases.
>>>> That doesn't prevent providing a library function which could be reused
>>>> by all those drivers. Nothing really too much different from
>>>> remap_pfn_range.
>>> And then in all the other use cases as well. It would be much easier if
>>> mmap could give you the memory you need instead of havig numerous drivers
>>> improvise on their own. This is in particular also useful
>>> for numerous embedded use cases where you need contiguous memory.
>> But a generic implementation would have to deal with many issues as
>> already mentioned. If you make this driver specific you can have access
>> control based on fd etc... I really fail to see how this is any
>> different from remap_pfn_range.
> Why have several driver specific implementation if you can generalize the idea and implement
> an already existing POSIX standard?

Just to be clear, the posix standard talks about a typed memory object.
The suggested implementation has one create a connection to the memory
object to receive a fd, then use mmap as usual to get a mapping backed
by contiguous pages/memory.  Of course, this type of implementation is
not a requirement.  However, this type of implementation looks quite a
bit like hugetlbfs today.
- Both require opening a special file/device, and then calling mmap on
  the returned fd.  You can technically use mmap(MAP_HUGETLB), but that
  still ends up using hugetbfs.  BTW, there was resistance to adding the
  MAP_HUGETLB flag to mmap.
- Allocation of contiguous memory is much like 'on demand' allocation of
  huge pages.  There are some (not many) users that use this model.  They
  attempt to allocate huge pages on demand, and if not available fall back
  to base pages.  This is how contiguous allocations would need to work.
  Of course, most hugetlbfs users pre-allocate pages for their use, and
  this 'might' be something useful for contiguous allocations as well.

I wonder if going down the path of a separate devide/filesystem/etc for
contiguous allocations might be a better option.  It would keep the
implementation somewhat separate.  However, I would then be afraid that
we end up with another 'separate/special vm' as in the case of hugetlbfs
today.

-- 
Mike Kravetz

Powered by blists - more mailing lists