From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 3F0394CC3; Thu, 15 Nov 2018 14:16:11 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2018 05:16:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,236,1539673200"; d="scan'208";a="86688670" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.124]) ([10.237.220.124]) by fmsmga008.fm.intel.com with ESMTP; 15 Nov 2018 05:16:09 -0800 To: Alejandro Lucero , dev@dpdk.org Cc: stable@dpdk.org References: <20181112111819.25087-1-alejandro.lucero@netronome.com> From: "Burakov, Anatoly" Message-ID: Date: Thu, 15 Nov 2018 13:16:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181112111819.25087-1-alejandro.lucero@netronome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 17.11] mem: fix memory initialization time 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, 15 Nov 2018 13:16:11 -0000 On 12-Nov-18 11:18 AM, Alejandro Lucero wrote: > When using large amount of hugepage based memory, doing all the > hugepages mapping can take quite significant time. > > The problem is hugepages being initially mmaped to virtual addresses > which will be tried later for the final hugepage mmaping. This causes > the final mapping requiring calling mmap with another hint address which > can happen several times, depending on the amount of memory to mmap, and > which each mmmap taking more than a second. > > This patch changes the hint for the initial hugepage mmaping using > a starting address which will not collide with the final mmaping. > > Fixes: 293c0c4b957f ("mem: use address hint for mapping hugepages") > > Signed-off-by: Alejandro Lucero > --- Hi Alejandro, I'm not sure i understand the purpose. When final mapping is performed, we reserve new memory area, and map pages into it. (i don't quite understand why we unmap the area before mapping pages, but it's how it's always been and i didn't change it in the legacy code) Which addresses are causing the collision? -- Thanks, Anatoly