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 829621B142 for ; Thu, 4 Oct 2018 15:15:55 +0200 (CEST) Received: by mail-ed1-f68.google.com with SMTP id c1-v6so8506311ede.5 for ; Thu, 04 Oct 2018 06:15:55 -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=SpTj4SUgNVr2oPWMhn57Zp10xjqSxH4TNT0Jxl8w0XI=; b=DhHwbvXay4gc58/lhhE0g9uRAwOhxFHGEHN+9a4AbOvBgA/BaX9E4SStO9da6vt8B0 1E42iqYVSqRRkFNQ4RaRimXa4hpTyA9seUmqQZN1BeaSrGRoYBC52uwyzj1M+5v7iXYB 8XFcrpqGO6fE8+ZU6wPIuMt6BYxutjzWpvcGfbhfAe9ez6aIJe6UAYoMJ0wcQ7Ln8YQ8 EF/n4wYjC5IiI6O/uW5meYW6wRGCsWcDGCaPZGzbEvzZcp0PUgtOJS1N7aVumTPCUZTz EDBMLgPjzqg/XaKfdbUOnJGxmVMC/M/OmtRbFPozoCrVoWnZkxeSywkjsdMyHLCVuvsn Pp1w== 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=SpTj4SUgNVr2oPWMhn57Zp10xjqSxH4TNT0Jxl8w0XI=; b=bApSIoZRW8BEetHO8hDzGiOPiw6dnb1LAvWO2Yg1rfiHjW94cRMmYnWuQ4E+dO22hL dOwY+OUqB6yxC/Xt6wrSN+vMhuu8RNHa5S+5nVKVBTW9v3na/HwwXRcBBdxTunZ2DyXY Obwd3OyH+CLiYwFgLBIIpWv+oPW37ILVAkNQjTiZFEkAGml7KflouBMZL3ILfjhWYZtf 6VMWWyL2q+M7ycSIvlqmi+Xb/R44e9+9I4PtJOGR0gki53H1m/PSuFkEoWjtEKO5FyYp T0wtGOENo9QQevF7jNvedssi73jT9TrUonrSdf4WixSgOiwFqZzVCxEcZAXYZao8uv0R 7QYg== X-Gm-Message-State: ABuFfogkpeD60Jlrsaa412Axfer+RNGwzXuAMQdkIrRJuUD8M3+9Xr3o amnp9Fwb0TCcNzdvLdGLJMfFyXu+9qa8dKcyxd4PnQ== X-Google-Smtp-Source: ACcGV6182Bv8LoJAnQ15Mj4t0IgyMsdfgOUHpr+hSNKM+n5W6UW2vDqZEyRRc5dZfNJD/k7z6k5Vmqi3H0Epm9joNGc= X-Received: by 2002:a17:906:70c3:: with SMTP id g3-v6mr6482807ejk.194.1538658955102; Thu, 04 Oct 2018 06:15:55 -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> <48acfd73-0a14-54c2-dfea-7e78235f6cf2@intel.com> In-Reply-To: <48acfd73-0a14-54c2-dfea-7e78235f6cf2@intel.com> From: Alejandro Lucero Date: Thu, 4 Oct 2018 14:15:43 +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 13:15:55 -0000 On Thu, Oct 4, 2018 at 1:08 PM Burakov, Anatoly wrote: > On 04-Oct-18 12:43 PM, Alejandro Lucero wrote: > > > > > > 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. > > Not sure i follow. Could you give an example of a scenario where leaving > huge chunks of memory free would be preferable to just adding page size > and starting from page-size-aligned address next time we allocate? > > Usually there is nothing at 4GB address in 64 bit processes, usually the text section being the first process region mapped and currently at far higher than 4GB. If there is something mapped there before executing the EAL hugepage/memory initialization code, not sure what it will be for, but maybe it needs to grow using contiguous virtual addresses. As I say, no idea what this could be used for, but the shorter the space when trying again in this code, the less likely that flexibility could be there. Maybe making the increment smaller just makes sense for virtual address space randomization for security reasons. Anyway, there is a lot of space with 64 bits, and, IMHO, this should not be a problem while the increment is negligible against 64 bits address space size, and 4GB are so negligible in this case as 4 bytes are to 4GB. > > > > -- > > Thanks, > > Anatoly > > > > > -- > Thanks, > Anatoly >