From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by dpdk.org (Postfix) with ESMTP id 2DEAA1B2B0 for ; Thu, 4 Oct 2018 13:43:31 +0200 (CEST) Received: by mail-ed1-f66.google.com with SMTP id g32-v6so8209584edg.13 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=eqbIVUztFUGNQpcx1wxg+fQuoJgmm2sm+8jGaInqXRuIXyQfOqIGC/pzNU5TMwQtk/ z0mQBkQcIit76byL3QPhtkShwPxKClYW5NhSKcf7DigtOeuoUIcokLuZ+akLjFVvXBtY z53wKV//tgBXNt7Sku8+DCNlU1LWBxGyb3OytEDQo8U2R58M6J8t3PWa3+h//0Mo/g2o GPBPnHcRgEuAw89holXE1qtJZjyJ2prWKd1SJFLTd4PXZ1pgSl/IIR92VGAhwnzGfouE N5SH7UPqE3OWCNok+TgfhyAYyLfhXSBc+wyz9r7xqbrX76O5qlPHAuPd0xbwVnES2YhK 1WDw== X-Gm-Message-State: ABuFfohP8PSK3zF4obde0OGZfpoU2rpkBkMAnIGB4Grdr8HEcM0BEUy+ VyPpvdoAa/1pvf2jE+RPWoMoF3kQl0xGmYx9rOk0Vw== 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-dev] [PATCH v2 2/5] 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: 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 >