Re: libhugetlbfs

["Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>]

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.

Sergio