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 76E871B618 for ; Thu, 21 Jun 2018 07:27:53 +0200 (CEST) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5L5NouW026748 for ; Thu, 21 Jun 2018 01:27:52 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2jqy6u41dy-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Jun 2018 01:27:52 -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:49 +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:46 +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 w5L5RjKa35061874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Jun 2018 05:27:45 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 863E542041; Thu, 21 Jun 2018 06:17:44 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F90F42047; Thu, 21 Jun 2018 06:17:43 +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:43 +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:37 +0530 X-Mailer: git-send-email 1.9.1 In-Reply-To: References: In-Reply-To: References: X-TM-AS-GCONF: 00 x-cbid: 18062105-0016-0000-0000-000001DE59DE X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18062105-0017-0000-0000-000032327203 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=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=819 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806210059 Subject: [dpdk-stable] [PATCH 2/3] eal: reorder calling munmap on zero-mapped memory 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:53 -0000 From: Gowrishankar Muthukrishnan In the current code path where secondary processes attaches memory mapped area that primary process created, it releases one by one zero-mapped memory in VA for the length of every iterated rte_memseg. PowerPC mm would not be able to respect address hint as secondary process would later ask to mmap hugepages in this freed area. For powerpc mm to respect address hint, its entire underlying memory slice (of about 1 TB in VA) should have been freed before re-mapping requested. So, we move this munmap() slightly above, from its current calling place so that, entire zero mapped area is alredy freed. Fixes: 284ae3e9ff ("eal/ppc: fix mmap for memory initialization") Cc: stable@dpdk.org Signed-off-by: Gowrishankar Muthukrishnan --- lib/librte_eal/linuxapp/eal/eal_memory.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c index 2dcb3b5..3dcd6c2 100644 --- a/lib/librte_eal/linuxapp/eal/eal_memory.c +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c @@ -1428,6 +1428,11 @@ void numa_error(char *where) } goto error; } + /* + * free previously mapped memory so we can map the + * hugepages into this space shortly + */ + munmap(base_addr, mcfg->memseg[s].len); } size = getFileSize(fd_hugepage); @@ -1445,12 +1450,7 @@ void numa_error(char *where) void *addr, *base_addr; uintptr_t offset = 0; size_t mapping_size; - /* - * free previously mapped memory so we can map the - * hugepages into the space - */ base_addr = mcfg->memseg[s].addr; - munmap(base_addr, mcfg->memseg[s].len); /* find the hugepages for this segment and map them * we don't need to worry about order, as the server sorted the -- 1.9.1