Re: [dpdk-dev] [PATCH] mem: balanced allocation of hugepages

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Feb 16, 2017 at 04:01:10PM +0300, Ilya Maximets wrote:
> Currently EAL allocates hugepages one by one not paying
> attention from which NUMA node allocation was done.
> 
> Such behaviour leads to allocation failure if number of
> available hugepages for application limited by cgroups
> or hugetlbfs and memory requested not only from the first
> socket.
> 
> Example:
> 	# 90 x 1GB hugepages availavle in a system
> 
> 	cgcreate -g hugetlb:/test
> 	# Limit to 32GB of hugepages
> 	cgset -r hugetlb.1GB.limit_in_bytes=34359738368 test
> 	# Request 4GB from each of 2 sockets
> 	cgexec -g hugetlb:test testpmd --socket-mem=4096,4096 ...
> 
> 	EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB
> 	EAL: 32 not 90 hugepages of size 1024 MB allocated
> 	EAL: Not enough memory available on socket 1!
> 	     Requested: 4096MB, available: 0MB
> 	PANIC in rte_eal_init():
> 	Cannot init memory
> 
> 	This happens beacause all allocated pages are
> 	on socket 0.
> 
> Fix this issue by setting mempolicy MPOL_PREFERRED for each
> hugepage to one of requested nodes in a round-robin fashion.
> In this case all allocated pages will be fairly distributed
> between all requested nodes.
> 
> New config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
> introduced and disabled by default because of external
> dependency from libnuma.
> 

I think this highlights a general technical problem we need to resolve
in DPDK. If we want to add support for a new feature in DPDK by
leveraging functionality in an existing library, we are caught in a sort
of catch-22:
* If we want to leverage the existing library, we have to have the
  feature off-by-default, as we don't want to increase the minimum
  requirements for DPDK.
* If we want the feature enabled by default we need to avoid the
  dependency, and so reimplement some or all of the functionality inside
  DPDK itself. That will be rejected on the basis that it duplicates
  existing library functionality.

I suspect the solution to this is more dynamic build-time configuration
to start enabling things based on installed dependencies, but I'm open
to other opinions. I see a gap here, however.

/Bruce