From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-f193.google.com (mail-it1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 320EE1F1C for ; Mon, 29 Oct 2018 17:08:18 +0100 (CET) Received: by mail-it1-f193.google.com with SMTP id p64-v6so10048749itp.0 for ; Mon, 29 Oct 2018 09:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=en1B9aqvEYDj7TZGTxVXleeeQUIulcKY1FUIzVE/jEM=; b=mgz+xRFbKJA60Y22gY9vfn3WD4/LkwNXjKhnDtLV5OZzcJUyVnAukTSaU5Swk/O97i qZOoJ9KRxk6CNH6mDmKFZbTzYBqX1i/LNl/nHs6nQsLaZ1VtOgAj+U1rid3CdkZSD0vf aSmK7OkRhru8dDed39BUxN+7zb3xR7cNm8QpXdvVLskQd9Ngrx6EpXc18UxfAKAK3Z+O cKXfxm+uQxdRMa08lTK4ZFgQYpWuXY8wptXZKPA7tzXpr5Nc8+rPV1MqBh/WbOv1nEMM 3iknFKsaZAhBShLwHH3qYTtZ9nZ7RELhx13oC573HVXRHk4HLXImmN/CTdPmVBeWb1am y72A== 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=en1B9aqvEYDj7TZGTxVXleeeQUIulcKY1FUIzVE/jEM=; b=Jew/4DKk+bzm9CGgYSDVhwgGUwZEocHed1ErLcT/zi5ot7IYzu3TbSR0LCivGOL9vn 4+Y5GQ/DW/JtFr+dyrmIHup5bw0FRDu7gUCnHWyAUyS296TCGu+4vcPfrj0moFvvT9AJ pm7CZFv5J2grU/Ki7EM2Us09k1BngGmUKsmXnfYILbL4hY0TLyIFLL+Pten1W2I+ZAvH WSVVr/1xrzWygyCXAqDycHZhCbj9YkijJQPbCxPtPAOJcP6LBpUFiyma9cVLhx/xXKOR t6Y0lmSaAOAFNxiXnfVY5OMZxojXuRx7haVe8e6ZjZBRAOR37qdY0eNsp0Dh9yf3Fxsc 5wOQ== X-Gm-Message-State: AGRZ1gJFjLvq/G3IS4BBbDGBHULR+Ekx5+DNpU7YqWwELqMYf1HaD68Y V4sxUpYBTikZ5e1nuY88BcEejfvXlsbpc0r1Af1B3tJW6SHuEQ== X-Google-Smtp-Source: AJdET5dwxdSoH3BhEBcFMGKO1POB4jy3qTAOgRfkJxexz/ZuKmu6KTqqVnFxeSDAznb/oZdSOm4ToZCCRT1VzD+yOvI= X-Received: by 2002:a02:a05:: with SMTP id 5-v6mr10949819jaw.6.1540829297472; Mon, 29 Oct 2018 09:08:17 -0700 (PDT) MIME-Version: 1.0 References: <1538743527-8285-1-git-send-email-alejandro.lucero@netronome.com> <1538743527-8285-3-git-send-email-alejandro.lucero@netronome.com> In-Reply-To: <1538743527-8285-3-git-send-email-alejandro.lucero@netronome.com> From: Dariusz Stojaczyk Date: Mon, 29 Oct 2018 17:08:06 +0100 Message-ID: To: alejandro.lucero@netronome.com, Thomas Monjalon , Anatoly Burakov Cc: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 2/6] mem: use address hint for mapping hugepages 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: Mon, 29 Oct 2018 16:08:19 -0000 On Fri, Oct 5, 2018 at 2:47 PM Alejandro Lucero wrote: > > Linux kernel uses a really high address as starting address for > serving mmaps calls. If there exist addressing limitations and > IOVA mode is VA, this starting address is likely too high for > those devices. However, it is possible to use a lower address in > the process virtual address space as with 64 bits there is a lot > of available space. > > This patch adds an address hint as starting address for 64 bits > systems and increments the hint for next invocations. If the mmap > call does not use the hint address, repeat the mmap call using > the hint address incremented by page size. > > Signed-off-by: Alejandro Lucero > Reviewed-by: Anatoly Burakov > --- > lib/librte_eal/common/eal_common_memory.c | 34 ++++++++++++++++++++++++++++++- > 1 file changed, 33 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c > index c482f0d..853c44c 100644 > --- a/lib/librte_eal/common/eal_common_memory.c > +++ b/lib/librte_eal/common/eal_common_memory.c > @@ -37,6 +37,23 @@ > static void *next_baseaddr; > static uint64_t system_page_sz; > > +#ifdef RTE_ARCH_64 > +/* > + * Linux kernel uses a really high address as starting address for serving > + * mmaps calls. If there exists addressing limitations and IOVA mode is VA, > + * this starting address is likely too high for those devices. However, it > + * is possible to use a lower address in the process virtual address space > + * as with 64 bits there is a lot of available space. > + * > + * Current known limitations are 39 or 40 bits. Setting the starting address > + * at 4GB implies there are 508GB or 1020GB for mapping the available > + * hugepages. This is likely enough for most systems, although a device with > + * addressing limitations should call rte_eal_check_dma_mask for ensuring all > + * memory is within supported range. > + */ > +static uint64_t baseaddr = 0x100000000; > +#endif This breaks running with ASAN unless a custom --base-virtaddr option is specified. The default base-virtaddr introduced by this patch falls into an area that's already reserved by ASAN. See here: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm The only available address space starts at 0x10007fff8000, which unfortunately doesn't fit in 39 bits. Right now the very first eal_get_virtual_area() in EAL initialization is used with 4KB pagesize, meaning that DPDK will try to mmap at each 4KB-aligned offset all the way from 0x100000000 to 0x10007fff8000, which takes quite a long, long time. I'm not sure about the solution to this problem, but I verify that starting DPDK 18.11-rc1 with `--base-virtaddr 0x200000000000` works just fine under ASAN. D. > >