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 C21CC1B618 for ; Thu, 21 Jun 2018 07:27:47 +0200 (CEST) Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5L5O8SX077564 for ; Thu, 21 Jun 2018 01:27:46 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2jr5je8m35-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Jun 2018 01:27:46 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 21 Jun 2018 06:27:44 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp04.uk.ibm.com (192.168.101.134) 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 06:27:41 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w5L5Rea635323932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Jun 2018 05:27:40 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6401E4203F; Thu, 21 Jun 2018 06:17:39 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1CB2B42041; Thu, 21 Jun 2018 06:17:38 +0100 (BST) Received: from chozha.in.ibm.com (unknown [9.124.35.60]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 21 Jun 2018 06:17:37 +0100 (BST) From: Gowrishankar To: Sergio Gonzalez Monroy , Bruce Richardson , Konstantin Ananyev Cc: stable@dpdk.org, Chao Zhu , Gowrishankar Muthukrishnan Date: Thu, 21 Jun 2018 10:57:35 +0530 X-Mailer: git-send-email 1.9.1 X-TM-AS-GCONF: 00 x-cbid: 18062105-0016-0000-0000-000001DE59DC X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18062105-0017-0000-0000-000032327201 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_02:, , 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=588 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806210059 Subject: [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 05:27:48 -0000 Content-Type: text/plain; charset="UTF-8" Message-ID: <20180621052735.MhaYSTDlmvCh7auvzo0BWoCf7syaqqPKECI6SZM18ao@z> 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 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(-) -- 1.9.1