On Fri, 13 Oct 2017, Michal Hocko wrote: > I would, quite contrary, suggest a device specific mmap implementation > which would guarantee both the best memory wrt. physical contiguous > aspect as well as the placement - what if the device have a restriction > on that as well? Contemporary high end devices can handle all of memory. If someone does not have the requirements to get all that hardware can give you in terms of speed then they also wont need contiguous memory. > > Yes, it remains contiguous. It is locked in memory. > > Hmm, so hugetlb on steroids... Its actually better because there is no requirements of allocation in exacytly 2M chunks. The remainder can be used for regular 4k page allocations. > > > Who is going to use such an interface? And probably many other > > > questions... > > > > Thanks for asking. I am just throwing out the idea of providing an interface > > for doing contiguous memory allocations from user space. There are at least > > two (and possibly more) devices that could benefit from such an interface. > > I am not really convinced this is a good interface. You are basically > trying to bypass virtual memory abstraction and that is quite > contradicting the mmap API to me. This is a standardized posix interface as described in our presentation at the plumbers conference. See the presentation on contiguous allocations. The contiguous allocations are particularly useful for the RDMA API which allows registering user space memory with devices. -- 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
