[dpdk-dev] [PATCH] eal/ppc: revert fix mmap for memory initialization

[dpdk-dev] [PATCH] eal/ppc: revert fix mmap for memory initialization

[Jonas Pfefferle]

This reverts commit 284ae3e9ff9a92575c28c858efd2c85c8de6d440
("eal/ppc: fix mmap for memory initialization").The logic if the
address hint is respected on mmap is no different on POWER than
on x86 however the address layout of userspace applications might
be slightly different i.e. you might need to use a different
virt-baseaddr. We now warn if the address hint is not respected
(fae209f) thus users can try different virtual address bases.

Fixes: 284ae3e9 ("eal/ppc: fix mmap for memory initialization")

Signed-off-by: Jonas Pfefferle <jpf@zurich.ibm.com>
---
 doc/guides/linux_gsg/sys_reqs.rst        |  6 ------
 lib/librte_eal/linuxapp/eal/eal_memory.c | 18 +++---------------
 2 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index 3e7fe63..ee69c1a 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -207,12 +207,6 @@ On a NUMA machine, pages should be allocated explicitly on separate nodes::
 
     For 1G pages, it is not possible to reserve the hugepage memory after the system has booted.
 
-    On IBM POWER system, the nr_overcommit_hugepages should be set to the same value as nr_hugepages.
-    For example, if the required page number is 128, the following commands are used::
-
-        echo 128 > /sys/kernel/mm/hugepages/hugepages-16384kB/nr_hugepages
-        echo 128 > /sys/kernel/mm/hugepages/hugepages-16384kB/nr_overcommit_hugepages
-
 Using Hugepages with the DPDK
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index ddf88c5..d92f163 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -273,14 +273,8 @@ get_virtual_area(size_t *size, size_t hugepage_sz)
 		return NULL;
 	}
 	do {
-		addr = mmap(addr,
-				(*size) + hugepage_sz, PROT_READ,
-#ifdef RTE_ARCH_PPC_64
-				MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,
-#else
-				MAP_PRIVATE,
-#endif
-				fd, 0);
+		addr = mmap(addr, (*size) + hugepage_sz,
+				PROT_READ, MAP_PRIVATE, fd, 0);
 		if (addr == MAP_FAILED)
 			*size -= hugepage_sz;
 	} while (addr == MAP_FAILED && *size > 0);
@@ -1391,13 +1385,7 @@ rte_eal_hugepage_attach(void)
 		 * use mmap to get identical addresses as the primary process.
 		 */
 		base_addr = mmap(mcfg->memseg[s].addr, mcfg->memseg[s].len,
-				 PROT_READ,
-#ifdef RTE_ARCH_PPC_64
-				 MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB,
-#else
-				 MAP_PRIVATE,
-#endif
-				 fd_zero, 0);
+				 PROT_READ, MAP_PRIVATE, fd_zero, 0);
 		if (base_addr == MAP_FAILED ||
 		    base_addr != mcfg->memseg[s].addr) {
 			max_seg = s;
-- 
2.7.4

Re: [dpdk-dev] [PATCH] eal/ppc: revert fix mmap for memory initialization

[Thomas Monjalon]

02/11/2017 14:58, Jonas Pfefferle:
> This reverts commit 284ae3e9ff9a92575c28c858efd2c85c8de6d440
> ("eal/ppc: fix mmap for memory initialization").The logic if the
> address hint is respected on mmap is no different on POWER than
> on x86 however the address layout of userspace applications might
> be slightly different i.e. you might need to use a different
> virt-baseaddr. We now warn if the address hint is not respected
> (fae209f) thus users can try different virtual address bases.

It depends on a patch which is not applied yet.