From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id CB52C1BB2E for ; Thu, 21 Jun 2018 10:54:13 +0200 (CEST) Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5L8o2gP064981 for ; Thu, 21 Jun 2018 04:54:12 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0a-001b2d01.pphosted.com with ESMTP id 2jr8sngav0-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Jun 2018 04:54:12 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 21 Jun 2018 09:54:10 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 21 Jun 2018 09:54:06 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w5L8s5dw17367150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Jun 2018 08:54:05 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 174D1A404D; Thu, 21 Jun 2018 09:44:45 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 134E9A4053; Thu, 21 Jun 2018 09:44:44 +0100 (BST) Received: from [9.124.35.60] (unknown [9.124.35.60]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 21 Jun 2018 09:44:43 +0100 (BST) To: Luca Boccassi , Sergio Gonzalez Monroy , Bruce Richardson , Konstantin Ananyev Cc: stable@dpdk.org, Chao Zhu References: <1529571053.6322.44.camel@debian.org> From: gowrishankar muthukrishnan Date: Thu, 21 Jun 2018 14:24:03 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1529571053.6322.44.camel@debian.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-GCONF: 00 x-cbid: 18062108-4275-0000-0000-000002903126 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18062108-4276-0000-0000-000037977DB9 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806210100 Subject: Re: [dpdk-stable] [PATCH 0/3] eal: clean up mapping hugepages in secondary process for ppc64le X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 08:54:14 -0000 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 >> >> 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 > 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