From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id A6EEF1BA42 for ; Fri, 27 Oct 2017 16:06:48 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 07:06:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,304,1505804400"; d="scan'208";a="1236095301" 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:06:45 -0700 To: Jonas Pfefferle1 , dev@dpdk.org Cc: chaozhu@linux.vnet.ibm.com, bruce.richardson@intel.com References: From: "Burakov, Anatoly" Message-ID: <921d836f-87dc-b017-2186-e70905f61612@intel.com> Date: Fri, 27 Oct 2017 15:06:44 +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=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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:06:49 -0000 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 ( > http://elixir.free-electrons.com/linux/latest/source/arch/powerpc/mm/mmap.c#L103 > ). 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. -- Thanks, Anatoly