[dpdk-dev] Is contiguous hugepages memory still required in latest DPDKs?

[Sergio Gonzalez Monroy]

The DPDK will still try to allocate contiguous hugepages.
Since DPDK v16.07 the mempool library is able to create a mempool with 
multiple chunks of memory.
You would still have the contig memory restriction for any other DPDK 
library or app.

Are you pre-allocating hugepages on boot (kernel cmdline) or runtime?

Sergio

On 21/03/2017 14:20, Ruslan Bilovol wrote:
> Hi,
>
> Recently after moving to 4.4 Linux kernel we found that DPDK v16.07
> can't find physically contiguous chunk of hugepages memory.
>
> I've tracked this down to kernel commits
>  81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
>  fff4068cba48 ("mm: page_alloc: revert NUMA aspect of fair allocation 
> policy")
>  4ffeaf3560a5 ("mm: page_alloc: reduce cost of the fair zone 
> allocation policy")
>
> These commits changed default page allocator behavior so it now allocates
> memory proportionally from preferred and lower zones. Hugepages
> are scattered proportionally among few memory zones, so possibility
> to find big physically contiguous chunk of hugepages memory is much 
> lower.
>
> I see that there were some attempts to move from contiguous hugepages
> approach, like http://dpdk.org/ml/archives/dev/2016-March/035201.html
> Also some discussion here: 
> http://dpdk.org/ml/archives/users/2016-October/001050.html
>
> The question: is contiguous hugepages memory still required in latest 
> DPDKs,
> and if not, since which version?
>
> Thanks,
> Ruslan
>