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

--
2.7.4

Tan, Jianfeng

2017-02-16 13:26:26 UTC

Hi,

-----Original Message-----
Sent: Thursday, February 16, 2017 9:01 PM
Cc: Heetae Ahn; Yuanhan Liu; Tan, Jianfeng; Neil Horman; Pei, Yulong; Ilya
Subject: [PATCH] mem: balanced allocation of hugepages
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.
# 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
Cannot init memory
This happens beacause all allocated pages are
on socket 0.

For such an use case, why not just use "numactl --interleave=0,1 <DPDK app> xxx"?

Do you see use case like --socket-mem 2048,1024 and only three 1GB-hugepage are allowed?

Thanks,
Jianfeng

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.
Fixes: 77988fc08dc5 ("mem: fix allocating all free hugepages")
---
config/common_base | 1 +
lib/librte_eal/Makefile | 4 ++
lib/librte_eal/linuxapp/eal/eal_memory.c | 66
++++++++++++++++++++++++++++++++
mk/rte.app.mk | 3 ++
4 files changed, 74 insertions(+)
diff --git a/config/common_base b/config/common_base
index 71a4fcb..fbcebbd 100644
--- a/config/common_base
+++ b/config/common_base
@@ -97,6 +97,7 @@ CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
CONFIG_RTE_EAL_IGB_UIO=n
CONFIG_RTE_EAL_VFIO=n
CONFIG_RTE_MALLOC_DEBUG=n
+CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES=n
# Default driver path (or "" to disable)
CONFIG_RTE_EAL_PMD_PATH=""
diff --git a/lib/librte_eal/Makefile b/lib/librte_eal/Makefile
index cf11a09..5ae3846 100644
--- a/lib/librte_eal/Makefile
+++ b/lib/librte_eal/Makefile
@@ -35,4 +35,8 @@ DIRS-y += common
DIRS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += linuxapp
DIRS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += bsdapp
+ifeq ($(CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES),y)
+LDLIBS += -lnuma
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index a956bb2..8536a36 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -82,6 +82,9 @@
#include <sys/time.h>
#include <signal.h>
#include <setjmp.h>
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+#include <numaif.h>
+#endif
#include <rte_log.h>
#include <rte_memory.h>
@@ -359,6 +362,21 @@ static int huge_wrap_sigsetjmp(void)
return sigsetjmp(huge_jmpenv, 1);
}
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+#ifndef ULONG_SIZE
+#define ULONG_SIZE sizeof(unsigned long)
+#endif
+#ifndef ULONG_BITS
+#define ULONG_BITS (ULONG_SIZE * CHAR_BIT)
+#endif
+#ifndef DIV_ROUND_UP
+#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
+#endif
+#ifndef BITS_TO_LONGS
+#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, ULONG_SIZE)
+#endif
+#endif
+
/*
* Mmap all hugepages of hugepage table: it first open a file in
* hugetlbfs, then mmap() hugepage_sz data in it. If orig is set, the
@@ -375,10 +393,48 @@ map_all_hugepages(struct hugepage_file
*hugepg_tbl,
void *virtaddr;
void *vma_addr = NULL;
size_t vma_len = 0;
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ unsigned long
nodemask[BITS_TO_LONGS(RTE_MAX_NUMA_NODES)] = {0UL};
+ unsigned long maxnode = 0;
+ int node_id = -1;
+
+ for (i = 0; i < RTE_MAX_NUMA_NODES; i++)
+ if (internal_config.socket_mem[i])
+ maxnode = i + 1;
+#endif
for (i = 0; i < hpi->num_pages[0]; i++) {
uint64_t hugepage_sz = hpi->hugepage_sz;
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ if (maxnode) {
+ node_id = (node_id + 1) % RTE_MAX_NUMA_NODES;
+ while (!internal_config.socket_mem[node_id])
+ node_id = (node_id + 1) %
RTE_MAX_NUMA_NODES;
+
+ nodemask[node_id / ULONG_BITS] =
+ 1UL << (node_id %
ULONG_BITS);
+
+ RTE_LOG(DEBUG, EAL,
+ "Setting policy MPOL_PREFERRED for
socket %d\n",
+ node_id);
+ /*
+ * Due to old linux kernel bug (feature?) we have to
+ * increase maxnode by 1. It will be unconditionally
+ * decreased back to normal value inside the syscall
+ * handler.
+ */
+ if (set_mempolicy(MPOL_PREFERRED,
+ nodemask, maxnode + 1) < 0) {
+ RTE_LOG(ERR, EAL,
+ "Failed to set policy
MPOL_PREFERRED: "
+ "%s\n", strerror(errno));
+ return i;
+ }
+
+ nodemask[node_id / ULONG_BITS] = 0UL;
+ }
+#endif
if (orig) {
hugepg_tbl[i].file_id = i;
hugepg_tbl[i].size = hugepage_sz;
@@ -489,6 +545,10 @@ map_all_hugepages(struct hugepage_file
*hugepg_tbl,
vma_len -= hugepage_sz;
}
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ if (maxnode && set_mempolicy(MPOL_DEFAULT, NULL, 0) < 0)
+ RTE_LOG(ERR, EAL, "Failed to set mempolicy
MPOL_DEFAULT\n");
+#endif
return i;
}
@@ -573,6 +634,11 @@ find_numasocket(struct hugepage_file *hugepg_tbl,
struct hugepage_info *hpi)
if (hugepg_tbl[i].orig_va == va) {
hugepg_tbl[i].socket_id = socket_id;
hp_count++;
+#ifdef RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
+ RTE_LOG(DEBUG, EAL,
+ "Hugepage %s is on socket %d\n",
+ hugepg_tbl[i].filepath, socket_id);
+#endif
}
}
}
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 92f3635..c2153b9 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -159,6 +159,9 @@ ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
# The static libraries do not know their dependencies.
# So linking with static library requires explicit dependencies.
_LDLIBS-$(CONFIG_RTE_LIBRTE_EAL) += -lrt
+ifeq ($(CONFIG_RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES),y)
+_LDLIBS-$(CONFIG_RTE_LIBRTE_EAL) += -lnuma
+endif
_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm
_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt
_LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lm
--
2.7.4

Ilya Maximets

2017-02-16 13:55:57 UTC

Hi,

Post by Tan, Jianfeng
Hi,

For such an use case, why not just use "numactl --interleave=0,1 <DPDK app> xxx"?

Unfortunately, interleave policy doesn't work for me. I suspect kernel configuration
blocks this or I don't understand something in kernel internals.
I'm using 3.10 rt kernel from rhel7.

I tried to set up MPOL_INTERLEAVE in code and it doesn't work for me. Your example
with numactl doesn't work too:

# Limited to 8GB of hugepages
cgexec -g hugetlb:test testpmd --socket-mem=4096,4096

EAL: Setting up physically contiguous memory...
EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB
EAL: 8 not 90 hugepages of size 1024 MB allocated
EAL: Hugepage /dev/hugepages/rtemap_0 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_1 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_2 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_3 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_4 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_5 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_6 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_7 is on socket 0
EAL: Not enough memory available on socket 1! Requested: 4096MB, available: 0MB
PANIC in rte_eal_init():
Cannot init memory

Also, using numactl will affect all the allocations in application. This may
cause additional unexpected issues.

Post by Tan, Jianfeng
Do you see use case like --socket-mem 2048,1024 and only three 1GB-hugepage are allowed?

This case will work with my patch.
But the opposite one '--socket-mem=1024,2048' will fail.
To be clear, we need to allocate all required memory at first
from each numa node and then allocate all other available pages
in round-robin fashion. But such solution looks a little ugly.

What do you think?

Best regards, Ilya Maximets.

Ilya Maximets

2017-02-16 13:57:36 UTC

Post by Ilya Maximets
Hi,

Post by Tan, Jianfeng
Hi,

For such an use case, why not just use "numactl --interleave=0,1 <DPDK app> xxx"?

Sorry,
cgexec -g hugetlb:test numactl --interleave=0,1 ./testpmd --socket-mem=4096,4096 ..

Post by Ilya Maximets
EAL: Setting up physically contiguous memory...
EAL: SIGBUS: Cannot mmap more hugepages of size 1024 MB
EAL: 8 not 90 hugepages of size 1024 MB allocated
EAL: Hugepage /dev/hugepages/rtemap_0 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_1 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_2 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_3 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_4 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_5 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_6 is on socket 0
EAL: Hugepage /dev/hugepages/rtemap_7 is on socket 0
EAL: Not enough memory available on socket 1! Requested: 4096MB, available: 0MB
Cannot init memory
Also, using numactl will affect all the allocations in application. This may
cause additional unexpected issues.

Post by Tan, Jianfeng
Do you see use case like --socket-mem 2048,1024 and only three 1GB-hugepage are allowed?

Bruce Richardson

2017-02-16 13:31:57 UTC

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

Ilya Maximets

2017-03-06 09:34:42 UTC

Hi all.

So, what about this change?

Best regards, Ilya Maximets.

Sergio Gonzalez Monroy

2017-03-08 13:46:26 UTC

Hi Ilya,

I have done similar tests and as you already pointed out, 'numactl
--interleave' does not seem to work as expected.
I have also checked that the issue can be reproduced with quota limit on
hugetlbfs mount point.

I would be inclined towards *adding libnuma as dependency* to DPDK to
make memory allocation a bit more reliable.

Currently at a high level regarding hugepages per numa node:
1) Try to map all free hugepages. The total number of mapped hugepages
depends if there were any limits, such as cgroups or quota in mount point.
2) Find out numa node of each hugepage.
3) Check if we have enough hugepages for requested memory in each numa
socket/node.

Using libnuma we could try to allocate hugepages per numa:
1) Try to map as many hugepages from numa 0.
2) Check if we have enough hugepages for requested memory in numa 0.
3) Try to map as many hugepages from numa 1.
4) Check if we have enough hugepages for requested memory in numa 1.

This approach would improve failing scenarios caused by limits but It
would still not fix issues regarding non-contiguous hugepages (worst
case each hugepage is a memseg).
The non-contiguous hugepages issues are not as critical now that
mempools can span over multiple memsegs/hugepages, but it is still a
problem for any other library requiring big chunks of memory.

Potentially if we were to add an option such as 'iommu-only' when all
devices are bound to vfio-pci, we could have a reliable way to allocate
hugepages by just requesting the number of pages from each numa.

Thoughts?

Sergio

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Ilya Maximets

2017-03-09 12:57:24 UTC

Post by Sergio Gonzalez Monroy
Hi Ilya,
I have done similar tests and as you already pointed out, 'numactl --interleave' does not seem to work as expected.
I have also checked that the issue can be reproduced with quota limit on hugetlbfs mount point.
I would be inclined towards *adding libnuma as dependency* to DPDK to make memory allocation a bit more reliable.
1) Try to map all free hugepages. The total number of mapped hugepages depends if there were any limits, such as cgroups or quota in mount point.
2) Find out numa node of each hugepage.
3) Check if we have enough hugepages for requested memory in each numa socket/node.
1) Try to map as many hugepages from numa 0.
2) Check if we have enough hugepages for requested memory in numa 0.
3) Try to map as many hugepages from numa 1.
4) Check if we have enough hugepages for requested memory in numa 1.
This approach would improve failing scenarios caused by limits but It would still not fix issues regarding non-contiguous hugepages (worst case each hugepage is a memseg).
The non-contiguous hugepages issues are not as critical now that mempools can span over multiple memsegs/hugepages, but it is still a problem for any other library requiring big chunks of memory.
Potentially if we were to add an option such as 'iommu-only' when all devices are bound to vfio-pci, we could have a reliable way to allocate hugepages by just requesting the number of pages from each numa.
Thoughts?

Hi Sergio,

Thanks for your attention to this.

For now, as we have some issues with non-contiguous
hugepages, I'm thinking about following hybrid schema:
1) Allocate essential hugepages:
1.1) Allocate as many hugepages from numa N to
only fit requested memory for this numa.
1.2) repeat 1.1 for all numa nodes.
2) Try to map all remaining free hugepages in a round-robin
fashion like in this patch.
3) Sort pages and choose the most suitable.

This solution should decrease number of issues connected with
non-contiguous memory.

Best regards, Ilya Maximets.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Sergio Gonzalez Monroy

2017-03-27 13:01:59 UTC

Hi Sergio,
Thanks for your attention to this.
For now, as we have some issues with non-contiguous
1.1) Allocate as many hugepages from numa N to
only fit requested memory for this numa.
1.2) repeat 1.1 for all numa nodes.
2) Try to map all remaining free hugepages in a round-robin
fashion like in this patch.
3) Sort pages and choose the most suitable.
This solution should decrease number of issues connected with
non-contiguous memory.

Sorry for late reply, I was hoping for more comments from the community.

IMHO this should be default behavior, which means no config option and
libnuma as EAL dependency.
I think your proposal is good, could you consider implementing such
approach on next release?

Regards.

Post by Ilya Maximets
Best regards, Ilya Maximets.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Acked-by: Sergio Gonzalez Monroy <***@intel.com>

Ilya Maximets

2017-03-27 14:43:15 UTC

Sorry for late reply, I was hoping for more comments from the community.
IMHO this should be default behavior, which means no config option and libnuma as EAL dependency.
I think your proposal is good, could you consider implementing such approach on next release?

Sure, I can implement this for 17.08 release.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Thanks.

Best regards, Ilya Maximets.

Ilya Maximets

2017-04-07 15:14:43 UTC

Hi All.

I wanted to ask (just to clarify current status):
Will this patch be included in current release (acked by maintainer)
and then I will upgrade it to hybrid logic or I will just prepare v3
with hybrid logic for 17.08 ?

Best regards, Ilya Maximets.

Sorry for late reply, I was hoping for more comments from the community.
IMHO this should be default behavior, which means no config option and libnuma as EAL dependency.
I think your proposal is good, could you consider implementing such approach on next release?

Sure, I can implement this for 17.08 release.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Thanks.
Best regards, Ilya Maximets.

Thomas Monjalon

2017-04-07 15:44:56 UTC

Post by Ilya Maximets
Hi All.
Will this patch be included in current release (acked by maintainer)
and then I will upgrade it to hybrid logic or I will just prepare v3
with hybrid logic for 17.08 ?

What is your preferred option Ilya?
Sergio?

Sorry for late reply, I was hoping for more comments from the community.
IMHO this should be default behavior, which means no config option and libnuma as EAL dependency.
I think your proposal is good, could you consider implementing such approach on next release?

Sure, I can implement this for 17.08 release.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Thanks.
Best regards, Ilya Maximets.

Ilya Maximets

2017-04-10 07:11:39 UTC

Post by Ilya Maximets
Hi All.
Will this patch be included in current release (acked by maintainer)
and then I will upgrade it to hybrid logic or I will just prepare v3
with hybrid logic for 17.08 ?

What is your preferred option Ilya?

I have no strong opinion on this. One thought is that it could be
nice if someone else could test this functionality with current
release before enabling it by default in 17.08.

Tomorrow I'm going on vacation. So I'll post rebased version today
(there are few fuzzes with current master) and you with Sergio may
decide what to do.

Best regards, Ilya Maximets.

Post by Thomas Monjalon
Sergio?

Sorry for late reply, I was hoping for more comments from the community.
IMHO this should be default behavior, which means no config option and libnuma as EAL dependency.
I think your proposal is good, could you consider implementing such approach on next release?

Sure, I can implement this for 17.08 release.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Thanks.
Best regards, Ilya Maximets.

Sergio Gonzalez Monroy

2017-04-10 07:51:52 UTC

Post by Ilya Maximets
Hi All.
Will this patch be included in current release (acked by maintainer)
and then I will upgrade it to hybrid logic or I will just prepare v3
with hybrid logic for 17.08 ?

What is your preferred option Ilya?

I have no strong opinion on this. One thought is that it could be
nice if someone else could test this functionality with current
release before enabling it by default in 17.08.
Tomorrow I'm going on vacation. So I'll post rebased version today
(there are few fuzzes with current master) and you with Sergio may
decide what to do.
Best regards, Ilya Maximets.

Post by Thomas Monjalon
Sergio?

I would be inclined towards v3 targeting v17.08. IMHO it would be more
clean this way.

Sergio

Sorry for late reply, I was hoping for more comments from the community.
IMHO this should be default behavior, which means no config option and libnuma as EAL dependency.
I think your proposal is good, could you consider implementing such approach on next release?

Sure, I can implement this for 17.08 release.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Thanks.
Best regards, Ilya Maximets.

Ilya Maximets

2017-04-10 08:05:56 UTC

Post by Ilya Maximets
Hi All.
Will this patch be included in current release (acked by maintainer)
and then I will upgrade it to hybrid logic or I will just prepare v3
with hybrid logic for 17.08 ?

What is your preferred option Ilya?

I have no strong opinion on this. One thought is that it could be
nice if someone else could test this functionality with current
release before enabling it by default in 17.08.
Tomorrow I'm going on vacation. So I'll post rebased version today
(there are few fuzzes with current master) and you with Sergio may
decide what to do.
Best regards, Ilya Maximets.

Post by Thomas Monjalon
Sergio?

I would be inclined towards v3 targeting v17.08. IMHO it would be more clean this way.

OK.
I've sent rebased version just in case.

Sergio

Sorry for late reply, I was hoping for more comments from the community.
IMHO this should be default behavior, which means no config option and libnuma as EAL dependency.
I think your proposal is good, could you consider implementing such approach on next release?

Sure, I can implement this for 17.08 release.

Post by Ilya Maximets
Hi all.
So, what about this change?
Best regards, Ilya Maximets.

Thanks.
Best regards, Ilya Maximets.

Ilya Maximets

2017-04-10 08:04:19 UTC

--
2.7.4

Thomas Monjalon

2017-04-10 10:03:50 UTC

Status: Changes Requested
per Sergio advice: "I would be inclined towards v3 targeting v17.08."

Ilya Maximets

2017-06-06 06:22:16 UTC

Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.

Version 2:
* rebased (fuzz in Makefile)

Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default

config/common_base | 2 +-
lib/librte_eal/Makefile | 2 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 87 ++++++++++++++++++++++++++++++--
mk/rte.app.mk | 1 +
4 files changed, 87 insertions(+), 5 deletions(-)

--
2.7.4

Ilya Maximets

2017-06-06 06:22:17 UTC

--
2.7.4

Ilya Maximets

2017-06-06 06:22:18 UTC

Since libnuma is added as a general dependency for EAL,
it is safe to enable LIBRTE_VHOST_NUMA by default.

Signed-off-by: Ilya Maximets <***@samsung.com>
---
config/common_base | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/common_base b/config/common_base
index c858769..db4cc1c 100644
--- a/config/common_base
+++ b/config/common_base
@@ -708,7 +708,7 @@ CONFIG_RTE_LIBRTE_PDUMP=y
# Compile vhost user library
#
CONFIG_RTE_LIBRTE_VHOST=n
-CONFIG_RTE_LIBRTE_VHOST_NUMA=n
+CONFIG_RTE_LIBRTE_VHOST_NUMA=y
CONFIG_RTE_LIBRTE_VHOST_DEBUG=n

#

--
2.7.4

Ilya Maximets

2017-06-06 08:13:50 UTC

Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.

Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.

Version 2:
* rebased (fuzz in Makefile)

Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default

config/common_base | 2 +-
lib/librte_eal/Makefile | 2 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 94 ++++++++++++++++++++++++++++++--
mk/rte.app.mk | 1 +
4 files changed, 94 insertions(+), 5 deletions(-)

--
2.7.4

Ilya Maximets

2017-06-06 08:13:51 UTC

--
2.7.4

Ilya Maximets

2017-06-06 08:13:52 UTC

--
2.7.4

Ilya Maximets

2017-06-06 13:33:38 UTC

Sorry for so frequent respinning of the series.

Version 5:
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)

Version 4:
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.

Version 3:
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.

Version 2:
* rebased (fuzz in Makefile)

Ilya Maximets (2):
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default

config/common_base | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 94 ++++++++++++++++++++++++++++++--
mk/rte.app.mk | 3 +
4 files changed, 95 insertions(+), 5 deletions(-)

--
2.7.4

Ilya Maximets

2017-06-06 13:33:39 UTC

--
2.7.4

Ilya Maximets

2017-06-06 13:33:40 UTC

--
2.7.4

Ilya Maximets

2017-06-08 11:21:58 UTC

Hi everyone,

I just want to clarify current status of these patches.
As I understand, moving to the new build system (for example,
meson+ninja as proposed[1] by Bruce) is a very long process.
But we have issues with imbalanced memory allocation now, and
IMHO it's better to fix them in a near future.

Latest version (v5) of balanced allocation patches adds linbuma
as general unconditional dependency which conflicts with the
current DPDK policies.

So, there are 2 option:

1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and disable it by default.

2. Keep patch as it is now and make everyone install libnuma
for successful build.

I have no preferences about above options. I'm asking your opinions.

Bruce, Sergio, Thomas, what do you think?

[1] http://dpdk.org/ml/archives/dev/2017-June/067428.html

Best regards, Ilya Maximets.

Post by Ilya Maximets
Sorry for so frequent respinning of the series.
* Fixed shared build. (Automated build test will fail
anyway because libnuma-devel not installed on build servers)
* Fixed work on systems without NUMA by adding check for NUMA
support in kernel.
* Implemented hybrid schema for allocation.
* Fixed not needed mempolicy change while remapping. (orig = 0)
* Added patch to enable VHOST_NUMA by default.
* rebased (fuzz in Makefile)
mem: balanced allocation of hugepages
config: enable vhost numa awareness by default
config/common_base | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal/linuxapp/eal/eal_memory.c | 94 ++++++++++++++++++++++++++++++--
mk/rte.app.mk | 3 +
4 files changed, 95 insertions(+), 5 deletions(-)

Bruce Richardson

2017-06-08 12:14:03 UTC

Post by Ilya Maximets
Hi everyone,
I just want to clarify current status of these patches.
As I understand, moving to the new build system (for example,
meson+ninja as proposed[1] by Bruce) is a very long process.
But we have issues with imbalanced memory allocation now, and
IMHO it's better to fix them in a near future.
Latest version (v5) of balanced allocation patches adds linbuma
as general unconditional dependency which conflicts with the
current DPDK policies.
1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and disable it by default.
2. Keep patch as it is now and make everyone install libnuma
for successful build.
I have no preferences about above options. I'm asking your opinions.
Bruce, Sergio, Thomas, what do you think?
[1] http://dpdk.org/ml/archives/dev/2017-June/067428.html
Best regards, Ilya Maximets.

I would be ok with having libnuma as a dependency, so I think I'd prefer
option 2 to 1, assuming libnuma is available in all major Linux distros.

/Bruce

Sergio Gonzalez Monroy

2017-06-08 15:44:49 UTC

Post by Bruce Richardson

I would be ok with having libnuma as a dependency, so I think I'd prefer
option 2 to 1, assuming libnuma is available in all major Linux distros.
/Bruce

+1 on option 2 (current patch and libnuma as DPDK dependency).

Sergio

Ilya Maximets

2017-06-14 06:11:27 UTC

Post by Bruce Richardson

I would be ok with having libnuma as a dependency, so I think I'd prefer
option 2 to 1, assuming libnuma is available in all major Linux distros.
/Bruce

+1 on option 2 (current patch and libnuma as DPDK dependency).
Sergio

Ok. In this case I'm waiting for review.

And someone need to install libnuma development package in automatic
build test environment. Otherwise there will be constant compilation
test failures like this:
http://dpdk.org/ml/archives/test-report/2017-June/021437.html

Best regards, Ilya Maximets.

Hemant Agrawal

2017-06-19 11:10:10 UTC

Post by Bruce Richardson

I would be ok with having libnuma as a dependency, so I think I'd prefer
option 2 to 1, assuming libnuma is available in all major Linux distros.
/Bruce

+1 on option 2 (current patch and libnuma as DPDK dependency).
Sergio

Ok. In this case I'm waiting for review.
And someone need to install libnuma development package in automatic
build test environment. Otherwise there will be constant compilation
http://dpdk.org/ml/archives/test-report/2017-June/021437.html
Best regards, Ilya Maximets.

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.

It can be added to the config, who desired to use it by default.

Thomas Monjalon

2017-06-20 13:07:11 UTC

Post by Ilya Maximets
1. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and disable it by default.
2. Keep patch as it is now and make everyone install libnuma
for successful build.

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

Ilya Maximets

2017-06-20 13:58:23 UTC

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

We're still don't have dynamic build time configuration system.
To make get/set_mempolicy work we need to include <numaif.h>
and have libnuma for successful linkage.
This means that the only option to not have libnuma as dependency
is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
as it was in the first version of the patch.

There is, actually, the third option (besides 2 already described):

3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and *enable* it by default.
In this case anyone who doesn't want to have libnuma as dependency
will be able to disable the config option manually.

Thomas, what do you think? Bruce? Sergio?

P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.

Thomas Monjalon

2017-06-20 14:35:28 UTC

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

We're still don't have dynamic build time configuration system.
To make get/set_mempolicy work we need to include <numaif.h>
and have libnuma for successful linkage.
This means that the only option to not have libnuma as dependency
is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
as it was in the first version of the patch.
3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and *enable* it by default.
In this case anyone who doesn't want to have libnuma as dependency
will be able to disable the config option manually.
Thomas, what do you think? Bruce? Sergio?

It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).

Post by Ilya Maximets
P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.

I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.

Sergio Gonzalez Monroy

2017-06-20 14:58:50 UTC

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

Ilya, I missed that libnuma is not supported on ARM.

Post by Ilya Maximets
We're still don't have dynamic build time configuration system.
To make get/set_mempolicy work we need to include <numaif.h>
and have libnuma for successful linkage.
This means that the only option to not have libnuma as dependency
is to return back configuration option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
as it was in the first version of the patch.
3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and *enable* it by default.
In this case anyone who doesn't want to have libnuma as dependency
will be able to disable the config option manually.
Thomas, what do you think? Bruce? Sergio?

It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).

Agree.

Post by Ilya Maximets
P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.

I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.

That is the simple way out.

Sergio

Sergio Gonzalez Monroy

2017-06-20 15:51:49 UTC

-----Original Message-----

Date: Tue, 20 Jun 2017 15:58:50 +0100
Subject: Re: [dpdk-dev] [PATCH v5 0/2] Balanced allocation of hugepages
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.1.1

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

Ilya, I missed that libnuma is not supported on ARM.

It is supported on arm64 and arm64 has NUMA machines(thunderx, thunderx2) too.
[dpdk.org] $ dpkg-query -L libnuma-dev
/.
/usr
/usr/lib
/usr/lib/aarch64-linux-gnu
/usr/lib/aarch64-linux-gnu/libnuma.a
/usr/share
/usr/share/man
/usr/share/man/man3
/usr/share/man/man3/numa.3.gz
/usr/share/doc
/usr/share/doc/libnuma-dev
/usr/share/doc/libnuma-dev/copyright
/usr/include
/usr/include/numaif.h
/usr/include/numa.h
/usr/include/numacompat1.h
/usr/lib/aarch64-linux-gnu/libnuma.so

Is it ARMv7 then the only supported arch missing libnuma support?

It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).

Agree.

Post by Ilya Maximets
P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.

I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.

That is the simple way out.
Sergio

Hemant Agrawal

2017-06-21 08:14:20 UTC

-----Original Message-----

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

Ilya, I missed that libnuma is not supported on ARM.

1. There are many machines (arm/ppc), which do not support NUMA.

https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

2. I could not locate it by default in Linaro toolchains.

3. Since this is not a common across all platform. This option should
not be added to the common_base or common configs. It can be added to
any architecture configuration, which needs it.

Regards,
Hemant

It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).

Agree.

Post by Ilya Maximets
P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.

I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.

That is the simple way out.
Sergio

Sergio Gonzalez Monroy

2017-06-21 08:25:25 UTC

-----Original Message-----

Post by Ilya Maximets
1. Return back config option
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and disable it by default.
2. Keep patch as it is now and make everyone install libnuma
for successful build.

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

Ilya, I missed that libnuma is not supported on ARM.

1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources,
but Jerin proved that there is support for it.

http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Post by Hemant Agrawal
2. I could not locate it by default in Linaro toolchains.
3. Since this is not a common across all platform. This option should
not be added to the common_base or common configs. It can be added to
any architecture configuration, which needs it.

So is it thunderx the only arm64 to enable this feature by default?
I thought the dependency was the libnuma library support itself.

Thanks,
Sergio

Post by Hemant Agrawal
Regards,
Hemant

Post by Ilya Maximets
We're still don't have dynamic build time configuration system.
To make get/set_mempolicy work we need to include <numaif.h>
and have libnuma for successful linkage.
This means that the only option to not have libnuma as dependency
is to return back configuration option
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
as it was in the first version of the patch.
3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and *enable* it by default.
In this case anyone who doesn't want to have libnuma as dependency
will be able to disable the config option manually.
Thomas, what do you think? Bruce? Sergio?

It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).

Agree.

Post by Ilya Maximets
P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.

I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.

That is the simple way out.
Sergio

Ilya Maximets

2017-06-21 08:36:16 UTC

-----Original Message-----

+1 for option 1
It will be a issue and undesired dependency for SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

Ilya, I missed that libnuma is not supported on ARM.

1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Post by Hemant Agrawal
2. I could not locate it by default in Linaro toolchains.
3. Since this is not a common across all platform. This option should not be added to the common_base or common configs. It can be added to any architecture configuration, which needs it.

So is it thunderx the only arm64 to enable this feature by default?
I thought the dependency was the libnuma library support itself.

ARMv7 is the only architecture without libnuma package in common distros.
So, in v6 I enabled this feature by default for x86, ppc and thunderx.
I didn't enable it for the whole ARMv8 just because thunderx is the only
platform which supports NUMA and has special defconfig in DPDK repository.

Best regards, Ilya Maximets.

It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).

Agree.

Post by Ilya Maximets
P.S. We're always able to implement syscall wrappers by hands without any
external dependencies, but I don't think it's a good decision.

I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.

That is the simple way out.
Sergio

Jerin Jacob

2017-06-21 08:41:58 UTC

-----Original Message-----

Date: Wed, 21 Jun 2017 09:25:25 +0100
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.1.1

-----Original Message-----

Post by Ilya Maximets
1. Return back config
option
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version
of the patch and disable it by
default.
2. Keep patch as it is now
and make everyone install
libnuma
for successful build.

+1 for option 1
It will be a issue and undesired dependency for
SoCs, not supporting
NUMA architecture.
It can be added to the config, who desired to use it by default.

Yes I agree, it cannot be a dependency for architectures which
do not support NUMA.
Please can we rework the patch so that only one node is assumed
if NUMA is disabled for the architecture?

Ilya, I missed that libnuma is not supported on ARM.

1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?

How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".

Some example in linux kernel build system:
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

So is it thunderx the only arm64 to enable this feature by default?
I thought the dependency was the libnuma library support itself.
Thanks,
Sergio

Post by Hemant Agrawal
Regards,
Hemant

Post by Ilya Maximets
We're still don't have dynamic build time configuration system.
To make get/set_mempolicy work we need to include <numaif.h>
and have libnuma for successful linkage.
This means that the only option to not have libnuma as dependency
is to return back configuration option
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
as it was in the first version of the patch.
3. Return back config option RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
from the first version of the patch and *enable* it by default.
In this case anyone who doesn't want to have
libnuma as dependency
will be able to disable the config option manually.
Thomas, what do you think? Bruce? Sergio?

It should be enabled on x86 and ppc, and disabled in other
default configurations (ARM for now).

Agree.

Post by Ilya Maximets
P.S. We're always able to implement syscall wrappers by
hands without any
external dependencies, but I don't think it's a good decision.

I agree to use libnuma instead of re-inventing the wheel.
Let's just make it optional at build time and fallback on one node
if disabled.

That is the simple way out.
Sergio

Thomas Monjalon

2017-06-21 08:49:14 UTC

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.
If someone really wants to build DPDK without NUMA for x86, he should
disable it in the build config file.

Jerin Jacob

2017-06-21 09:27:45 UTC

-----Original Message-----

Date: Wed, 21 Jun 2017 10:49:14 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.

I have installed libnuma on a NUMA and non NUMA machine.
Compiled and ran following code on those machine and it could detect
the numa availability. Could you add more details on the "error on
platform supporting NUMA".

➜ 83xx [ctest] $ cat main.c
#include <numaif.h>
#include <stdio.h>
#include <errno.h>

int main()
{
/* Check if kernel supports NUMA. */
if (get_mempolicy(NULL, NULL, 0, 0, 0) < 0 && errno == ENOSYS) {
printf("NUMA is not supported.\n");
} else {
printf("NUMA is supported.\n");
}

}
➜ 83xx [ctest] $ gcc -Wall main.c -lnuma
# On non numa system
➜ 83xx [ctest] $ ./a.out
NUMA is not supported

# On numa machine
➜ GB-2S [~] $ ./a.out
NUMA is supported.

If someone really wants to build DPDK without NUMA for x86, he should
disable it in the build config file.

Thomas Monjalon

2017-06-21 09:58:12 UTC

-----Original Message-----

Date: Wed, 21 Jun 2017 10:49:14 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.

I was saying that we do not need to detect NUMA.
If we are building DPDK for a NUMA architecture and libnuma is not
available, then it will be a problem that the user must catch.
The easiest way to catch it, is to fail on the include of numaif.h.

Jerin Jacob

2017-06-21 10:29:41 UTC

-----Original Message-----

Date: Wed, 21 Jun 2017 11:58:12 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

-----Original Message-----

Date: Wed, 21 Jun 2017 10:49:14 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.

libnuma is not really _architecture_ depended.

Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.

IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.

No strong opinion on "failing the build" vs "printing a warning" in the
absence of numaif.h

Ilya Maximets

2017-06-21 10:36:58 UTC

-----Original Message-----

Date: Wed, 21 Jun 2017 11:58:12 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

-----Original Message-----

Date: Wed, 21 Jun 2017 10:49:14 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.

libnuma is not really _architecture_ depended.
Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.
IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.

Detecting of headers is impossible until dpdk doesn't have dynamic build
configuration system like autotools, CMake or meson.
Right now we just can't do that.

No strong opinion on "failing the build" vs "printing a warning" in the
absence of numaif.h

Jerin Jacob

2017-06-21 11:22:43 UTC

-----Original Message-----

Date: Wed, 21 Jun 2017 13:36:58 +0300
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0

-----Original Message-----

Date: Wed, 21 Jun 2017 11:58:12 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

-----Original Message-----

Date: Wed, 21 Jun 2017 10:49:14 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.

libnuma is not really _architecture_ depended.
Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.
IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.

Detecting of headers is impossible until dpdk doesn't have dynamic build
configuration system like autotools, CMake or meson.
Right now we just can't do that.

I agree. Unless if we do something like linux kernel does it below
http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh

Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.

No strong opinion on "failing the build" vs "printing a warning" in the
absence of numaif.h

Thomas Monjalon

2017-06-21 11:29:31 UTC

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.

libnuma is not really _architecture_ depended.
Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.
IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.

Detecting of headers is impossible until dpdk doesn't have dynamic build
configuration system like autotools, CMake or meson.
Right now we just can't do that.

I agree. Unless if we do something like linux kernel does it below
http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.

In this case, you can enable it in common_base and disable it only for
armv7 and dpaa2.

Hemant Agrawal

2017-06-27 09:13:55 UTC

-----Original Message-----

Date: Wed, 21 Jun 2017 13:36:58 +0300
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0

-----Original Message-----

Date: Wed, 21 Jun 2017 11:58:12 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

-----Original Message-----

Date: Wed, 21 Jun 2017 10:49:14 +0200
Subject: Re: [PATCH v5 0/2] Balanced allocation of hugepages

Post by Hemant Agrawal
1. There are many machines (arm/ppc), which do not support NUMA.
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

I did find that link too, last modified 4 years ago.
Despite that, I could not find any ARM references in libnuma sources, but
Jerin proved that there is support for it.
http://oss.sgi.com/projects/libnuma/
https://github.com/numactl/numactl

Those Linaro links are very old. ARM64 NUMA supported has been added in 4.7 kernel.
I guess we are talking about build time time dependency with libnuma here.
Correct? I think, Even with old arm64 kernel(< 4.6), You can build against
libnuma if it is present in rootfs. Just that at runtime, it will return
NUMA support not available. Correct?
How hard is detect the presence of "numaif.h" if existing build system does not
support it? If it trivial, we can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES
if build environment has "numaif.h".
http://lxr.linux.no/linux+v4.10.1/scripts/gcc-goto.sh

I think we should not try to detect numaif.h, because it should be
an error on platform supporting NUMA.

libnuma is not really _architecture_ depended.
Ilya Maximets patch disables NUMA support in common arm64 config.I
think, It is not correct, We should not disable on any archs generic config.
IMO, It should be enabled by default in common config and then we can
detect the presence of numaif.h, if not available OR a target does not need it
explicitly, proceed with disabling
RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES. I think, That is more portable.

Detecting of headers is impossible until dpdk doesn't have dynamic build
configuration system like autotools, CMake or meson.
Right now we just can't do that.

I agree. Unless if we do something like linux kernel does it below
http://elixir.free-electrons.com/linux/latest/source/scripts/kconfig/lxdialog/check-lxdialog.sh
Either way, I think, you can enable RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES in
generic arm64 config and disable on defconfig_arm64-dpaa2-linuxapp-gcc(as Hemant requested) or
any sub arch target that does not need in RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES.

No, this is not acceptable. it should not be enabled in generic arm64.
It can be enabled in specific ARM platforms, which support NUMA
architecture.
We also use generic ARM code on various of our platform when running
with non-dpaa and/or virtio-net. So enabling it will break all those
platforms.

No strong opinion on "failing the build" vs "printing a warning" in the
absence of numaif.h

Thomas Monjalon

2017-06-27 09:26:28 UTC