From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by dpdk.org (Postfix) with ESMTP id D43062BD8 for ; Fri, 16 Nov 2018 15:43:06 +0100 (CET) Received: by mail-ed1-f49.google.com with SMTP id a2-v6so19851803edi.5 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=CuqOHG1nj2L99EB/yABeDo0hrNYvLFZGDqclqf7aItlVh6jbYo2w1zlmbfCfiinyz/ JjemmCfElYEUb5V9IAIXGaJFn84mZb7zDn2HY9gkrRuNMMOm/wJrdzfHzGghRxxkH3Fp 6rmaj9fzK8uYbuS7CqQmzXyrUbJ76rUxZMfzYKUn3Oam+baiOIHHU3VDAB/Ynah0vWMz 03MyBfVWFZswkAF7TRWBVeoPkZL0hDs+oMadp+Dzig5eQzC8BlcupydSDtXOsONqEQda k1w9NxPgzbe8qAQh4ZZEgPCfZC0xj2isQ4q1c02naITPfU9VC51E1t7cWOITxRRHNp2X IHXQ== X-Gm-Message-State: AGRZ1gI3keARAz5SdCSThLUKfRynhlJs0VbE5Ah/cSPI0o+NRLcQKBF1 owdBKRBOW4/XwuOWK8k1b63yMD2nDvQaeuj7N5oJNQ== 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-stable] [dpdk-dev] [PATCH 17.11] mem: fix memory initialization time X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches 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 >