From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 5147D1E20 for ; Thu, 6 Apr 2017 14:59:00 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP; 06 Apr 2017 05:58:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,159,1488873600"; d="scan'208";a="74357890" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.23]) ([10.237.221.23]) by orsmga004.jf.intel.com with ESMTP; 06 Apr 2017 05:58:45 -0700 To: Chao Zhu , dev@dpdk.org References: <1491473170-25160-1-git-send-email-chaozhu@linux.vnet.ibm.com> <1491473170-25160-2-git-send-email-chaozhu@linux.vnet.ibm.com> Cc: Gowrishankar , david.marchand@6wind.com From: Sergio Gonzalez Monroy Message-ID: <4de077b0-6ca4-2905-ec09-e1a200cda1b0@intel.com> Date: Thu, 6 Apr 2017 13:58:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1491473170-25160-2-git-send-email-chaozhu@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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, 06 Apr 2017 12:59:03 -0000 Hi Chao, You mentioned that 'mmap will not respect the requested address hint', how does the proposed change solves that? Is it that hugepages map to a specific VA region, and without MAP_HUGETLB you may get address from wrong region? If mmap were to respect the hinted address, we could do this change multi-arch without having to set overcommit hugepages? fd = -1 addr = mmap(addr, (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, fd, 0) # Free hugepages mapping addr = mmap(addr, (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, fd, 0) What do you think? Regards, Sergio 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 = 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 == MAP_FAILED) > *size -= hugepage_sz; > } while (addr == 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 = 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 == MAP_FAILED || > base_addr != mcfg->memseg[s].addr) { > max_seg = s;