From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 7B6E337B4; Thu, 4 Oct 2018 14:08:37 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2018 05:08:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,338,1534834800"; d="scan'208";a="78433512" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.113]) ([10.237.220.113]) by orsmga007.jf.intel.com with ESMTP; 04 Oct 2018 05:08:27 -0700 To: Alejandro Lucero Cc: dev , dpdk stable 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> From: "Burakov, Anatoly" Message-ID: <48acfd73-0a14-54c2-dfea-7e78235f6cf2@intel.com> Date: Thu, 4 Oct 2018 13:08:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 12:08:38 -0000 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? > > -- > Thanks, > Anatoly > -- Thanks, Anatoly