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

[gowrishankar muthukrishnan]

On Thursday 21 June 2018 02:20 PM, Luca Boccassi wrote:
> On Thu, 2018-06-21 at 10:57 +0530, Gowrishankar wrote:
>> From: Gowrishankar Muthukrishnan <gowrishankar.m at 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 at dpdk.org
>>
>> Signed-off-by: Gowrishankar Muthukrishnan <gowrishankar.m at 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.
>
Sure Luca. This patch set is for v17.11 based LTS.

Thanks,
Gowrishankar