diff mbox series

[v3] mem: Fix anonymous mapping on Power9.

Message ID 20181116173538.5321-1-dwilder@us.ibm.com (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers
Series [v3] mem: Fix anonymous mapping on Power9. |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/mellanox-Performance-Testing success Performance Testing PASS
ci/intel-Performance-Testing success Performance Testing PASS
ci/Intel-compilation success Compilation OK

Commit Message

David Wilder Nov. 16, 2018, 5:35 p.m. UTC 
  Removed the use of MAP_HUGETLB for anonymous mapping on ppc64.  The
MAP_HUGETLB had previously been added to workaround issues on IBM Power8
systems when mapping /dev/zero (see: commit
284ae3e9ff9a92575c28c858efd2c85c8de6d440).  In the current code the
MAP_HUGETLB flag will cause the anonymous mapping to fail on Power9.
Note, Power8 is currently failing to correctly mmap Hugepages, with and
without this change.

Signed-off-by: David Wilder <dwilder@us.ibm.com>
Reviewed-by: Pradeep Satyanarayana <pradeep@us.ibm.com>
---
V2- Updated release notes.
V3- fixed spelling.

 MAINTAINERS                                | 2 +-
 doc/guides/linux_gsg/sys_reqs.rst          | 6 ------
 doc/guides/rel_notes/release_18_11.rst     | 1 +
 lib/librte_eal/linuxapp/eal/eal_memalloc.c | 3 ---
 lib/librte_eal/linuxapp/eal/eal_memory.c   | 4 ----
 5 files changed, 2 insertions(+), 14 deletions(-)

Comments

Thomas Monjalon Nov. 18, 2018, 1:41 p.m. UTC | #1 
16/11/2018 18:35, David Wilder:
> Removed the use of MAP_HUGETLB for anonymous mapping on ppc64.  The
> MAP_HUGETLB had previously been added to workaround issues on IBM Power8
> systems when mapping /dev/zero (see: commit
> 284ae3e9ff9a92575c28c858efd2c85c8de6d440).  In the current code the
> MAP_HUGETLB flag will cause the anonymous mapping to fail on Power9.
> Note, Power8 is currently failing to correctly mmap Hugepages, with and
> without this change.
> 
> Signed-off-by: David Wilder <dwilder@us.ibm.com>
> Reviewed-by: Pradeep Satyanarayana <pradeep@us.ibm.com>

Applied, thanks

Note: Cc stable@dpdk.org does not make sense in this context.
Backporting this patch to 17.11 would be a mistake,
and 17.08 is probably not in Power9 scope.
Kevin Traynor Nov. 27, 2018, 10:50 a.m. UTC | #2 
On 11/18/2018 01:41 PM, Thomas Monjalon wrote:
> 16/11/2018 18:35, David Wilder:
>> Removed the use of MAP_HUGETLB for anonymous mapping on ppc64.  The
>> MAP_HUGETLB had previously been added to workaround issues on IBM Power8
>> systems when mapping /dev/zero (see: commit
>> 284ae3e9ff9a92575c28c858efd2c85c8de6d440).  In the current code the
>> MAP_HUGETLB flag will cause the anonymous mapping to fail on Power9.
>> Note, Power8 is currently failing to correctly mmap Hugepages, with and
>> without this change.
>>
>> Signed-off-by: David Wilder <dwilder@us.ibm.com>
>> Reviewed-by: Pradeep Satyanarayana <pradeep@us.ibm.com>
> 
> Applied, thanks
> 
> Note: Cc stable@dpdk.org does not make sense in this context.
> Backporting this patch to 17.11 would be a mistake,
> and 17.08 is probably not in Power9 scope.
> 

I think 17.08 is a typo for 18.08? Anyway, I won't backport to 18.08
unless I hear something further.

> 
>
Thomas Monjalon Feb. 18, 2019, 3:46 p.m. UTC | #3 
Hi,

Long time no talk about the IBM Power support status.

16/11/2018 18:35, David Wilder:
> --- a/doc/guides/rel_notes/release_18_11.rst
> +++ b/doc/guides/rel_notes/release_18_11.rst
> +* IBM Power8 is not supported by this release of DPDK. IBM Power9 is supported.

The config file is defconfig_ppc_64-power8-linuxapp-gcc.
Given that only Power9 is supported, should we rename it?

Is there more changes required to make Power9 working with the latest DPDK?
Chao Zhu Feb. 20, 2019, 8:07 a.m. UTC | #4 
+Pradeep

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, February 18, 2019 11:47 PM
> To: David Wilder <dwilder@us.ibm.com>
> Cc: dev@dpdk.org; chaozhu@linux.vnet.ibm.com
> Subject: Re: [dpdk-stable] [PATCH v3] mem: Fix anonymous mapping on
> Power9.
>
> Hi,
>
> Long time no talk about the IBM Power support status.
>
> 16/11/2018 18:35, David Wilder:
> > --- a/doc/guides/rel_notes/release_18_11.rst
> > +++ b/doc/guides/rel_notes/release_18_11.rst
> > +* IBM Power8 is not supported by this release of DPDK. IBM Power9 is
> supported.
>
> The config file is defconfig_ppc_64-power8-linuxapp-gcc.
> Given that only Power9 is supported, should we rename it?
>
> Is there more changes required to make Power9 working with the latest DPDK?
>
Burakov, Anatoly Feb. 20, 2019, 4:04 p.m. UTC | #5 
On 16-Nov-18 5:35 PM, David Wilder wrote:
> Removed the use of MAP_HUGETLB for anonymous mapping on ppc64.  The
> MAP_HUGETLB had previously been added to workaround issues on IBM Power8
> systems when mapping /dev/zero (see: commit
> 284ae3e9ff9a92575c28c858efd2c85c8de6d440).  In the current code the
> MAP_HUGETLB flag will cause the anonymous mapping to fail on Power9.
> Note, Power8 is currently failing to correctly mmap Hugepages, with and
> without this change.
> 
> Signed-off-by: David Wilder <dwilder@us.ibm.com>
> Reviewed-by: Pradeep Satyanarayana <pradeep@us.ibm.com>
> ---

The changes are contained entirely to POWER9 code paths/docs, so while i 
cannot verify them working for obvious reasons, i have no objections to 
this patch.

Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Thomas Monjalon Feb. 20, 2019, 4:27 p.m. UTC | #6 
20/02/2019 17:04, Burakov, Anatoly:
> On 16-Nov-18 5:35 PM, David Wilder wrote:
> > Removed the use of MAP_HUGETLB for anonymous mapping on ppc64.  The
> > MAP_HUGETLB had previously been added to workaround issues on IBM Power8
> > systems when mapping /dev/zero (see: commit
> > 284ae3e9ff9a92575c28c858efd2c85c8de6d440).  In the current code the
> > MAP_HUGETLB flag will cause the anonymous mapping to fail on Power9.
> > Note, Power8 is currently failing to correctly mmap Hugepages, with and
> > without this change.
> > 
> > Signed-off-by: David Wilder <dwilder@us.ibm.com>
> > Reviewed-by: Pradeep Satyanarayana <pradeep@us.ibm.com>
> > ---
> 
> The changes are contained entirely to POWER9 code paths/docs, so while i 
> cannot verify them working for obvious reasons, i have no objections to 
> this patch.
> 
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

It was applied a long time ago :)
Burakov, Anatoly Feb. 20, 2019, 4:44 p.m. UTC | #7 
On 20-Feb-19 4:27 PM, Thomas Monjalon wrote:
> 20/02/2019 17:04, Burakov, Anatoly:
>> On 16-Nov-18 5:35 PM, David Wilder wrote:
>>> Removed the use of MAP_HUGETLB for anonymous mapping on ppc64.  The
>>> MAP_HUGETLB had previously been added to workaround issues on IBM Power8
>>> systems when mapping /dev/zero (see: commit
>>> 284ae3e9ff9a92575c28c858efd2c85c8de6d440).  In the current code the
>>> MAP_HUGETLB flag will cause the anonymous mapping to fail on Power9.
>>> Note, Power8 is currently failing to correctly mmap Hugepages, with and
>>> without this change.
>>>
>>> Signed-off-by: David Wilder <dwilder@us.ibm.com>
>>> Reviewed-by: Pradeep Satyanarayana <pradeep@us.ibm.com>
>>> ---
>>
>> The changes are contained entirely to POWER9 code paths/docs, so while i
>> cannot verify them working for obvious reasons, i have no objections to
>> this patch.
>>
>> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> 
> It was applied a long time ago :)
> 

I can see that now :) Someone replied to it and it bubbled up my inbox...
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 19353ac89..c4d2fd086 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -233,7 +233,7 @@  F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
 F: drivers/net/i40e/i40e_rxtx_vec_neon.c
 F: drivers/net/virtio/virtio_rxtx_simple_neon.c
 
-IBM POWER
+IBM POWER (alpha)
 M: Chao Zhu <chaozhu@linux.vnet.ibm.com>
 F: lib/librte_eal/common/arch/ppc_64/
 F: lib/librte_eal/common/include/arch/ppc_64/
diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index e2230f37b..c02ec28c1 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -183,12 +183,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/doc/guides/rel_notes/release_18_11.rst b/doc/guides/rel_notes/release_18_11.rst
index 51d007582..a271badbe 100644
--- a/doc/guides/rel_notes/release_18_11.rst
+++ b/doc/guides/rel_notes/release_18_11.rst
@@ -532,6 +532,7 @@  Known Issues
   driver; the Linux netvsc device must be brought up before the netvsc device is
   unbound and passed to the DPDK.
 
+* IBM Power8 is not supported by this release of DPDK. IBM Power9 is supported.
 
 Tested Platforms
 ----------------
diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
index 48b9c7360..784939566 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
@@ -753,9 +753,6 @@  alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
 	munmap(addr, alloc_sz);
 unmapped:
 	flags = MAP_FIXED;
-#ifdef RTE_ARCH_PPC_64
-	flags |= MAP_HUGETLB;
-#endif
 	new_addr = eal_get_virtual_area(addr, &alloc_sz, alloc_sz, 0, flags);
 	if (new_addr != addr) {
 		if (new_addr != NULL)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 48b23ce19..6f94621d4 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -847,10 +847,6 @@  alloc_va_space(struct rte_memseg_list *msl)
 	void *addr;
 	int flags = 0;
 
-#ifdef RTE_ARCH_PPC_64
-	flags |= MAP_HUGETLB;
-#endif
-
 	page_sz = msl->page_sz;
 	mem_sz = page_sz * msl->memseg_arr.len;