From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by dpdk.org (Postfix) with ESMTP id BF0312C23 for ; Thu, 13 Apr 2017 03:40:56 +0200 (CEST) Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3D1XjXG139993 for ; Wed, 12 Apr 2017 21:40:56 -0400 Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) by mx0b-001b2d01.pphosted.com with ESMTP id 29snvjh7ev-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Apr 2017 21:40:55 -0400 Received: from localhost by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Apr 2017 11:40:51 +1000 Received: from d23relay10.au.ibm.com (202.81.31.229) by e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 13 Apr 2017 11:40:49 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay10.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v3D1edmj49545252 for ; Thu, 13 Apr 2017 11:40:47 +1000 Received: from d23av04.au.ibm.com (localhost [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v3D1eEGr001689 for ; Thu, 13 Apr 2017 11:40:14 +1000 Received: from ADMINIB2M8Q79C ([9.186.60.148]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id v3D1eDq0001403; Thu, 13 Apr 2017 11:40:13 +1000 From: "Chao Zhu" To: "'Sergio Gonzalez Monroy'" , Cc: "'Gowrishankar'" , References: <1491473170-25160-1-git-send-email-chaozhu@linux.vnet.ibm.com> <1491473170-25160-2-git-send-email-chaozhu@linux.vnet.ibm.com> <4de077b0-6ca4-2905-ec09-e1a200cda1b0@intel.com> In-Reply-To: <4de077b0-6ca4-2905-ec09-e1a200cda1b0@intel.com> Date: Thu, 13 Apr 2017 09:40:00 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGnyeQ4cCn416xz/x7QX+0WHt+TIQGcrdvWApL+rTSh9tsXoA== Content-Language: zh-cn X-TM-AS-MML: disable x-cbid: 17041301-0044-0000-0000-000002419CB0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041301-0045-0000-0000-000006C886B6 Message-Id: <000401d2b3f6$e8047a60$b80d6f20$@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704130010 Subject: Re: [dpdk-dev] [PATCH 1/2] eal/ppc: fix mmap for memory initialization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 01:40:57 -0000 Sergio, Thanks for the comments! On POWER, if it doesn't specify the MAP_HUGETLB flag when doing mapping, = it may get the addresses from other regions. However, the address space = size of hugepages is exactly the same as the value specified by user when doing initialization. There will be not enough space for mmap twice in DPDK. That's why we need to set the overcommit to expand the address space. > -----Original Message----- > From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy@intel.com] > Sent: 2017=C4=EA4=D4=C26=C8=D5 20:59 > To: Chao Zhu ; dev@dpdk.org > Cc: Gowrishankar ; > david.marchand@6wind.com > Subject: Re: [PATCH 1/2] eal/ppc: fix mmap for memory initialization >=20 > Hi Chao, >=20 > You mentioned that 'mmap will not respect the requested address hint', = how > does the proposed change solves that? >=20 > Is it that hugepages map to a specific VA region, and without = MAP_HUGETLB > you may get address from wrong region? >=20 > If mmap were to respect the hinted address, we could do this change > multi-arch without having to set overcommit hugepages? >=20 > fd =3D -1 > addr =3D mmap(addr, (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE | > MAP_ANONYMOUS | MAP_HUGETLB, fd, 0) # Free hugepages mapping addr =3D > mmap(addr, (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE | > MAP_ANONYMOUS, fd, 0) >=20 > What do you think? >=20 > Regards, > Sergio >=20 > On 06/04/2017 11:06, Chao Zhu wrote: > > On IBM POWER platform, when mapping /dev/zero file to hugepage = memory > > space, mmap will not respect the requested address hint. This will > > cause the memory initilization for the second process fails. This > > patch adds the required mmap flags to make it work. Beside this, = users > > need to set the nr_overcommit_hugepages to expand the VA range. When > > doing the initilization, users need to set both nr_hugepages and > > nr_overcommit_hugepages to the same value, like 64, 128, etc. > > > > Signed-off-by: Chao Zhu > > --- > > lib/librte_eal/linuxapp/eal/eal_memory.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c > > b/lib/librte_eal/linuxapp/eal/eal_memory.c > > index a956bb2..e06186b 100644 > > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c > > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c > > @@ -313,7 +313,11 @@ int rte_xen_dom0_supported(void) > > } > > do { > > addr =3D mmap(addr, > > +#ifndef RTE_ARCH_PPC_64 > > (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE, fd, > 0); > > +#else > > + (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE | > > +MAP_ANONYMOUS | MAP_HUGETLB, fd, 0); #endif > > if (addr =3D=3D MAP_FAILED) > > *size -=3D hugepage_sz; > > } while (addr =3D=3D MAP_FAILED && *size > 0); @@ -1330,7 = +1334,11 > @@ > > static int huge_wrap_sigsetjmp(void) > > * use mmap to get identical addresses as the primary process. > > */ > > base_addr =3D mmap(mcfg->memseg[s].addr, > mcfg->memseg[s].len, > > +#ifndef RTE_ARCH_PPC_64 > > PROT_READ, MAP_PRIVATE, fd_zero, 0); > > +#else > > + PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS | > > +MAP_HUGETLB, fd_zero, 0); #endif > > if (base_addr =3D=3D MAP_FAILED || > > base_addr !=3D mcfg->memseg[s].addr) { > > max_seg =3D s; >=20