2015-07-23 10:29, Gonzalez Monroy, Sergio: > On 23/07/2015 09:12, Thomas Monjalon wrote: > > 2015-07-23 08:34, Gonzalez Monroy, Sergio: > >> On 22/07/2015 11:40, Thomas Monjalon wrote: > >>> Sergio, > >>> > >>> As the maintainer of memory allocation, would you consider using > >>> libhugetlbfs in DPDK for Linux? > >>> It may simplify a part of our memory allocator and avoid some potential > >>> bugs which would be already fixed in the dedicated lib. > >> I did have a look at it a couple of months ago and I thought there were > >> a few issues: > >> - get_hugepage_region/get_huge_pages only allocates default size huge pages > >> (you can set a different default huge page size with environment > >> variables but no > >> support for multiple sizes) plus we have no guarantee on physically > >> contiguous pages. > > Speaking about that, we don't always need contiguous pages. > > Maybe we should take it into account when reserving memory. > > Some flags DMA (locked physical pages that are not swappable) and CONTIGUOUS > > may be considered. > Sure. I think I also mentioned this as possible future work in the > Dynamic Memzones RFC. > >> - That leave us with > >> hugetlbfs_unlinked_fd/hugetlbfs_unlinked_fd_for_size. These APIs > >> wouldn't simplify a lot the current code, just the allocation of the > >> pages themselves > >> (ie. creating a file in hugetlbfs mount). > >> Then there is the issue with multi-process; because they return a > >> file descriptor while > >> unlinking the file, we would need some sort of Inter-Process > >> Communication to pass > >> the descriptors to secondary processes. > >> - Not a big deal but AFAIK it is not possible to have multiple mount > >> points for the same > >> hugepage size, and even if you do, hugetlbfs_find_path_for_size > >> returns always the > >> same path (ie. first found in list). > >> - We still need to parse /proc/self/pagemap to get physical address of > >> mapped hugepages. > >> > >> I guess that if we were to push for a new API such as > >> hugetlbfs_fd_for_size, we could use > >> it for the hugepage allocation, but we still would have to parse > >> /proc/self/pagemap to get > >> physical address and then order those hugepages. > >> > >> Thoughts? > > Why not extending the API and pushing our code to this lib? > > It would allow to share the maintenance. > > > > The same move could be done to libpciaccess. > I don't disagree with the idea of using libhugetlbfs, I just tried to > point out that > it's not just a drop in replacement.
Yes, thank you for the fine analysis, Sergio.
