Re: [dpdk-dev] [PATCH v6 1/2] mem: balanced allocation of hugepages

2017-06-21 Thread Bruce Richardson
On Wed, Jun 21, 2017 at 12:25:51PM +0300, Ilya Maximets wrote: > On 21.06.2017 11:58, Bruce Richardson wrote: > > On Wed, Jun 21, 2017 at 10:51:58AM +0200, Thomas Monjalon wrote: > >> 21/06/2017 10:04, Ilya Maximets: > >>> +CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES=n > >> > >> We can stop insertin

Re: [dpdk-dev] [PATCH v6 1/2] mem: balanced allocation of hugepages

2017-06-21 Thread Thomas Monjalon
21/06/2017 10:58, Bruce Richardson: > On Wed, Jun 21, 2017 at 10:51:58AM +0200, Thomas Monjalon wrote: > > 21/06/2017 10:04, Ilya Maximets: > > > +CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES=n > > > > We can stop inserting LIBRTE in our config options. > > CONFIG_RTE_EAL_ is long enough :) > > > C

Re: [dpdk-dev] [PATCH v6 1/2] mem: balanced allocation of hugepages

2017-06-21 Thread Ilya Maximets
On 21.06.2017 11:58, Bruce Richardson wrote: > On Wed, Jun 21, 2017 at 10:51:58AM +0200, Thomas Monjalon wrote: >> 21/06/2017 10:04, Ilya Maximets: >>> +CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES=n >> >> We can stop inserting LIBRTE in our config options. >> CONFIG_RTE_EAL_ is long enough :) >> > C

Re: [dpdk-dev] [PATCH v6 1/2] mem: balanced allocation of hugepages

2017-06-21 Thread Bruce Richardson
On Wed, Jun 21, 2017 at 10:51:58AM +0200, Thomas Monjalon wrote: > 21/06/2017 10:04, Ilya Maximets: > > +CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES=n > > We can stop inserting LIBRTE in our config options. > CONFIG_RTE_EAL_ is long enough :) > Consistency. While I agree it's unneeded should have

Re: [dpdk-dev] [PATCH v6 1/2] mem: balanced allocation of hugepages

2017-06-21 Thread Thomas Monjalon
21/06/2017 10:04, Ilya Maximets: > +CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES=n We can stop inserting LIBRTE in our config options. CONFIG_RTE_EAL_ is long enough :)

[dpdk-dev] [PATCH v6 1/2] mem: balanced allocation of hugepages

2017-06-21 Thread Ilya Maximets
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: