From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by dpdk.org (Postfix) with ESMTP id 372711B394 for ; Thu, 4 Oct 2018 13:43:31 +0200 (CEST) Received: by mail-ed1-f68.google.com with SMTP id y19-v6so8270460edd.2 for ; Thu, 04 Oct 2018 04:43:31 -0700 (PDT) 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=C0kWV9KsgbkcRDaF4nMB9TasRe04UkZ2CrWUINqrci0=; b=zLX0/oSbQwP3aUln0y69+i7j4AGyqIuj8eYlqw4aeuC1R1g+ciFyvL9/KoG95v2i5q itqHLP8RD4oHmq8zEHjEoeeBjSZcXV/nt4CF5faASkj1A6PhLf8rAb750stAHZ4MGBzh 32E29maHVG2Xr6VSpunTcxxT8Q8QpJGw8aVlTxCArE0yCRInBMzHuTmnykQQxfDrNgG3 oojtoq89WQzqZuUHiuyh/4kyAMCP6ymFQbJgFYQ8O8uIAtoD4aOAbiBX+5Om/5QypwBm 1TjHUAXBz1oIJGWiGbY4JDdEtpHSvT974rrsWCfAJ5nDK0K7lPeV/AcKvsC/drT/pil6 R+eg== 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=C0kWV9KsgbkcRDaF4nMB9TasRe04UkZ2CrWUINqrci0=; b=CiqPb2YTe2fMYjLb2Q1yPapSuEp4Iqh98yol+sLJAFgtjzWWBGDvzfxYeUUnYKxbZF AfANfLKmv86ZCJv7WM86yb1ehzUW/Licp7ofH5wuo1Fj3JA43cdS6cIZgN1FppZ2xfq4 o8+vANYYWVUB8S0o8RK5HRIQrmQiG7IYzYdxrL26fCoBkfvc2FBdogz0/Bze2KKT+/5t StcJE3AFKJPfPC6osAxt6OQp1kMX9adDvbBEp705jcC5fV7HCqWMmqeUvRSzbpJx2/GM KIejqnR+LFwwJeW6iJ7ZIfvXr33Glk+ps7c38tA9TrcvBwZtAL6LHz8SIQW7y2FJh2Ea CzEA== X-Gm-Message-State: ABuFfohoRbl8MwgUKfCBoRkIrrbyPl5fYwok5QMXqC1Ui2BSxQKQWxHk CZb0spurrzvLO4ymWOPHq5uDXOsRQWnLUVKUFXh+RQ== X-Google-Smtp-Source: ACcGV63ghC/pDkfkBbTc3t3rNvmLsTh1D6RipfQtIBvG+flRQoE9IYGXCf1Z0AFOv8pJjt0it5x+pyfj6e0/7tkvK5M= X-Received: by 2002:a17:906:70c3:: with SMTP id g3-v6mr6089978ejk.194.1538653410832; Thu, 04 Oct 2018 04:43:30 -0700 (PDT) MIME-Version: 1.0 References: <1535719857-19092-1-git-send-email-alejandro.lucero@netronome.com> <1535719857-19092-3-git-send-email-alejandro.lucero@netronome.com> <6bddf8bd-ecc0-5170-7265-e49488909f4e@intel.com> In-Reply-To: <6bddf8bd-ecc0-5170-7265-e49488909f4e@intel.com> From: Alejandro Lucero Date: Thu, 4 Oct 2018 12:43:19 +0100 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 v2 2/5] mem: use address hint for mapping hugepages 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: Thu, 04 Oct 2018 11:43:31 -0000 On Wed, Oct 3, 2018 at 1:50 PM Burakov, Anatoly wrote: > On 31-Aug-18 1:50 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. > > > > Signed-off-by: Alejandro Lucero > > --- > > > > > > > mapped_addr = mmap(requested_addr, (size_t)map_sz, > PROT_READ, > > mmap_flags, -1, 0); > > + > > if (mapped_addr == MAP_FAILED && allow_shrink) > > Unintended whitespace change? > > Yes. I'll fix it. > > *size -= page_sz; > > - } while (allow_shrink && mapped_addr == MAP_FAILED && *size > 0); > > + > > + if (mapped_addr != MAP_FAILED && addr_is_hint && > > + mapped_addr != requested_addr) { > > + /* hint was not used. Try with another offset */ > > + munmap(mapped_addr, map_sz); > > + mapped_addr = MAP_FAILED; > > + next_baseaddr = RTE_PTR_ADD(next_baseaddr, > 0x100000000); > > Why not increment by page size? Sure, it could take some more time to > allocate, but will result in less wasted memory. > > I though the same or even using smaller increments than hugepage size. Increment the address in such amount does not mean we are wasting memory but just leaving space if some mmap fails. I think it is better to leave as much as space as possible just in case the data allocated in the conflicted area would need to grow in the future. > -- > Thanks, > Anatoly >