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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
