From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id BCB6E1BB16 for ; Fri, 27 Oct 2017 16:44:56 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 07:44:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,304,1505804400"; d="scan'208";a="1236118738" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.210.134]) ([10.237.210.134]) by fmsmga002.fm.intel.com with ESMTP; 27 Oct 2017 07:44:53 -0700 To: Jonas Pfefferle1 Cc: bruce.richardson@intel.com, chaozhu@linux.vnet.ibm.com, dev@dpdk.org References: <921d836f-87dc-b017-2186-e70905f61612@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 27 Oct 2017 15:44:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] Huge mapping secondary process linux 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: Fri, 27 Oct 2017 14:44:57 -0000 On 27-Oct-17 3:28 PM, Jonas Pfefferle1 wrote: > "Burakov, Anatoly" wrote on 10/27/2017 > 04:06:44 PM: > > > From: "Burakov, Anatoly" > > To: Jonas Pfefferle1 , dev@dpdk.org > > Cc: chaozhu@linux.vnet.ibm.com, bruce.richardson@intel.com > > Date: 10/27/2017 04:06 PM > > Subject: Re: [dpdk-dev] Huge mapping secondary process linux > > > > On 27-Oct-17 1:43 PM, Jonas Pfefferle1 wrote: > > > > > > > > > Hi @all, > > > > > > I'm trying to make sense of the hugepage memory mappings in > > > librte_eal/linuxapp/eal/eal_memory.c: > > > * In rte_eal_hugepage_attach (line 1347) when we try to do a private > > > mapping on /dev/zero (line 1393) why do we not use MAP_FIXED if we > need the > > > addresses to be identical with the primary process? > > > * On POWER we have this weird business going on where we use > MAP_HUGETLB > > > because according to this commit: > > > > > > commit 284ae3e9ff9a92575c28c858efd2c85c8de6d440 > > > Author: Chao Zhu > > > Date:   Thu Apr 6 15:36:09 2017 +0530 > > > > > >      eal/ppc: fix mmap for memory initialization > > > > > >      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 initialization 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 initialization, users need to set both nr_hugepages and > > >      nr_overcommit_hugepages to the same value, like 64, 128, etc. > > > > > > mmap address hints are not respected. Looking at the mmap code in the > > > kernel this is not true entirely however under some circumstances > the hint > > > can be ignored ( > > > https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__elixir.free-2Delectrons.com_linux_latest_source_arch_powerpc_mm_mmap.c-23L103&d=DwICaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=rOdXhRsgn8Iur7bDE0vgwvo6TC8OpoDN- > > pXjigIjRW0&m=cttQcHlAYixhsYS3lz- > > BAdEeg4dpbwGdPnj2R3I8Do0&s=Gp0TIjUtIed05Jgb7XnlocpCYZdFXZXiH0LqIWiNMhA&e= > > > ). However I believe we can remove the extra case for PPC if we use > > > MAP_FIXED when doing the secondary process mappings because we need > them to > > > be identical anyway. We could also use MAP_FIXED when doing the primary > > > process mappings resp. get_virtual_area if we want to have any > guarantees > > > when specifying a base address. Any thoughts? > > > > > > Thanks, > > > Jonas > > > > > hi Jonas, > > > > MAP_FIXED is not used because it's dangerous, it unmaps anything that is > > already mapped into that space. We would rather know that we can't map > > something than unwittingly unmap something that was mapped before. > > Ok, I see. Maybe we can add a check to the primary process's memory > mappings whether the hint has been respected or not? At least warn if it > hasn't. Hi Jonas, I'm unfamiliar with POWER platform, so i'm afraid you'd have to explain a bit more what you mean by "hint has been respected" :) -- Thanks, Anatoly