From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by dpdk.org (Postfix) with ESMTP id E1F7D47CE for ; Fri, 16 Nov 2018 15:43:06 +0100 (CET) Received: by mail-ed1-f44.google.com with SMTP id x30so15124067edx.2 for ; Fri, 16 Nov 2018 06:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w965gMwWxEnByr3LX4Peg9r6hj+/3Wvy5lKM5LYhu5g=; b=Dczr5L8V47Df65GLxEIwVnjWmYVQlwn4avD+huBRaj/XWJiae1ddJiXN5YN/GF31vt 6oly76vyJycd+f84lkj6xSE8uuGRd9WVd/DZxVetXl312hUm+ngz9EO82fsfS8HgxrXP BvQQ59lw1IlVkQ0Wsc6V6VfxTHM47fylVo1atFSakwTisewnHQWimB+avys/OXEyY5LI ZvIJs/OssFvOmhyaO/PpVgTkBvnE0I7u52JIUBVoRO4cMWMXapdbYIcpfxLn77TjC2TI 477hp81pWmmGQwC18S9dbCY2r9WaWMaBh5C+P+/TMN/+hhd3ZcOKRRhnsFaM1pWMfsOH eVzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w965gMwWxEnByr3LX4Peg9r6hj+/3Wvy5lKM5LYhu5g=; b=VTkb6+gHVgfuJB2ZddFCap1B4Lpq5+fC2p/iABq11qHciXchMav14YXN2Nye94CuNA zIHByTT59ckye7bVD/Kg4O45mK6/jzpY7Zw49/Cq/ixSOo87XCLQajO5fOsu15mTxfLv szIdqGpuq8llWjSyZgQcnAwC7muqPUZgdXUsXL0PIpz6mhxBQJPu7EZNRd4Z3ANmOTtn C/AJEz9h0ltRomrzJGriPGrKX2bwZvptF3G1hIiExG8Aapeq6oiiogXITM/i9ewtW/RE gJPKWEWKW26JwWM4HWBEH68ilTUAs6vKt4G7Su4yfJl7vnoo6Ek0Qj3sI0yX8PdbHcVH 9zKQ== X-Gm-Message-State: AGRZ1gKmyD5XRy+Y6cqIoMkKzH0I6Wk+T0zmIkNCmAowcAIfmzKZZl9V ydnfSLmWX2GN5j/Mfm35l8t6wmS9wgGUSVoQzFYlcw== X-Google-Smtp-Source: AJdET5fn0WcGdirUS1MsMTz/NBVi0d2oHEGpqW0l7qXER5TazRSKkNSrnQUh3N/xa8eXsXrGc7ECJRkS5TGaPu3UUVo= X-Received: by 2002:a17:906:3da2:: with SMTP id y2-v6mr8938842ejh.160.1542379386515; Fri, 16 Nov 2018 06:43:06 -0800 (PST) MIME-Version: 1.0 References: <20181112111819.25087-1-alejandro.lucero@netronome.com> <431aff9c-4d26-8c81-04d4-49b274c13ee1@intel.com> In-Reply-To: <431aff9c-4d26-8c81-04d4-49b274c13ee1@intel.com> From: Alejandro Lucero Date: Fri, 16 Nov 2018 14:42:55 +0000 Message-ID: To: "Burakov, Anatoly" Cc: dev , dpdk stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Fri, 16 Nov 2018 14:43:07 -0000 On Fri, Nov 16, 2018 at 1:35 PM Burakov, Anatoly wrote: > On 16-Nov-18 12:49 PM, Alejandro Lucero wrote: > > > > > > On Thu, Nov 15, 2018 at 1:16 PM Burakov, Anatoly > > > wrote: > > > > 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? > > > > > > Because the hint for the final mapping is at 4GB address, and the > > hugepages are initially individually mapped starting at low virtual > > addresses, when the memory to map is 4GB or higher, the hugepages will > > end using that hint address and higher. The more the hugepages to mmap, > > the more addresses above the hint address are used, and the more mmaps > > failed for getting the virtual addresses for the final mmap. > > Yes, but i still don't understand what the problem is. > > Before the final mapping, all of the pages get unmapped. They no longer > occupy any VA space at all. Then, we create a VA-area the size of > IOVA-contiguous chunk we have, but then we also unmap *that* (again, no > idea why we actually do that, but that's how it works). So, the final > mapping is performed with the knowledge that there are no pages at > specified addresses, and mapping for specified addresses is performed > when the first mapping has already been unmapped. > > As far as i understand, at no point do we hold addresses for initial and > final mappings concurrently. So, where does the conflict come in? > > Are you sure about this? Because I can see calling unmap_all_hugepage_init happens after the second call to map_all_hugepages. Maybe you are looking at the legacy code in a newer version which is not exactly doing the same steps. > > > > -- > > Thanks, > > Anatoly > > > > > -- > Thanks, > Anatoly >