Re: [dpdk-stable] [PATCH 0/3] eal: clean up mapping hugepages in secondary process for ppc64le

[Luca Boccassi <bluca@debian.org>]

On Thu, 2018-06-21 at 10:57 +0530, Gowrishankar wrote:
> From: Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>
> 
> Earlier powerpc arch encountered an issue in secondary process
> to map hugepages in same VA range as mapped by primary process.
> By then, proposed fix was to use nr_overcommit_hugepages from 
> the kernel and mmap using MAP_HUGETLB|MAP_ANONYMOUS flags. Though
> it solved respecting address hints in mmap calls, this fix
> introduced limitation of maximum VA space that, primary process
> in DPDK can create upon hugepages, to physical RAM size (almost).
> 
> This patch cleans up this limitation by
> 
>  1. reverting the previous patch so that, virtual address space
>     range is not a constraint (like other arch).
>         
>  2. reverse-indexing on hugepage files as the secondary
>     process mmap them. Reversed addressing sequence makes 
>     this mandate.
>     
>  3. Move slightly where munmap() is called in zero-mapped VA
>     block, as secondary process would attach them.
>     
> All these changes has also been verified in x86 arch (and request
> other arch maintainers too test this and give feedback).
> 
> Fixes: 284ae3e9ff ("eal/ppc: fix mmap for memory initialization")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.
> ibm.com>
> 
> 
> Gowrishankar Muthukrishnan (3):
>   eal: access hugepage_file in reverse order for powerpc
>   eal: reorder calling munmap on zero-mapped memory
>   eal: reverse powerpc changes done for hugepage overcommit
> 
>  doc/guides/linux_gsg/sys_reqs.rst        |  6 ------
>  lib/librte_eal/linuxapp/eal/eal_memory.c | 22 +++++++++-------------
>  2 files changed, 9 insertions(+), 19 deletions(-)

Hi,

which stable releases are these patches aimed at?

In the future, please consider using git send-email with --subject-
prefix 'PATCH xx.yy' so that it's included in the subject.

-- 
Kind regards,
Luca Boccassi