Messages in this thread | | | Date | Wed, 19 Aug 2009 17:48:11 +1200 | Subject | Re: [PATCH 0/3]HTLB mapping for drivers (take 2) | From | Alexey Korolev <> |
| |
Hi, > > It sounds like this patch set working towards the same goal as my > MAP_HUGETLB set. The only difference I see is you allocate huge page > at a time and (if I am understanding the patch) fault the page in > immediately, where MAP_HUGETLB only faults pages as needed. Does the > MAP_HUGETLB patch set provide the functionality that you need, and if > not, what can be done to provide what you need? > > Eric > Thanks a lot for willing to help. I'll be much appreciate if you have an interesting idea how HTLB mapping for drivers can be done.
It is better to describe use case in order to make it clear what needs to be done. Driver provides mapping of device DMA buffers to user level applications. User level applications process the data. Device is using a master DMA to send data to the user buffer, buffer size can be >1GB and performance is very important. (So huge pages mapping really makes sense.)
In addition we have to mention that: 1. It is hard for user to tell how much huge pages needs to be reserved by the driver. 2. Devices add constrains on memory regions. For example it needs to be contiguous with in the physical address space. It is necessary to have ability to specify special gfp flags. 3 The HW needs to access physical memory before the user level software can access it. (Hugetlbfs picks up pages on page fault from pool). It means memory allocation needs to be driven by device driver.
Original idea was: create hugetlbfs file which has common mapping with device file. Allocate memory. Populate page cache of hugetlbfs file with allocated pages. When fault occurs, page will be taken from page cache and then remapped to user space by hugetlbfs.
Another possible approach is described here: http://marc.info/?l=linux-mm&m=125065257431410&w=2 But currently not sure will it work or not.
Thanks, Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |