DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Alejandro Lucero <alejandro.lucero@netronome.com>
Cc: dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 2/5] mem: use address hint for mapping hugepages
Date: Thu, 4 Oct 2018 13:08:26 +0100	[thread overview]
Message-ID: <48acfd73-0a14-54c2-dfea-7e78235f6cf2@intel.com> (raw)
In-Reply-To: <CAD+H991=1mW0Xsd-+4FgajbZJjs1a2sqJMeOTTH5xFXTkzDzrg@mail.gmail.com>

On 04-Oct-18 12:43 PM, Alejandro Lucero wrote:
> 
> 
> On Wed, Oct 3, 2018 at 1:50 PM Burakov, Anatoly 
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> 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 <alejandro.lucero@netronome.com
>     <mailto:alejandro.lucero@netronome.com>>
>      > ---
> 
>     <snip>
> 
>      >
>      >               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

  reply	other threads:[~2018-10-04 12:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 12:50 [dpdk-dev] [PATCH v2 0/5] use IOVAs check based on DMA mask Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 1/5] mem: add function for checking memsegs IOVAs addresses Alejandro Lucero
2018-10-03 12:43   ` Burakov, Anatoly
     [not found]     ` <CAD+H991m6qauwX+P=muKe6bAjNLUrcBaGbxFXkMV60OVNvRgPg@mail.gmail.com>
2018-10-04 12:59       ` [dpdk-dev] Fwd: " Alejandro Lucero
2018-10-04 15:39         ` Burakov, Anatoly
2018-10-04 17:41           ` Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 2/5] mem: use address hint for mapping hugepages Alejandro Lucero
2018-10-03 12:50   ` Burakov, Anatoly
2018-10-04 11:43     ` Alejandro Lucero
2018-10-04 12:08       ` Burakov, Anatoly [this message]
2018-10-04 13:15         ` Alejandro Lucero
2018-10-04 15:43           ` Burakov, Anatoly
2018-10-04 17:58             ` Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 3/5] bus/pci: use IOVAs check when setting IOVA mode Alejandro Lucero
2018-10-03 12:55   ` Burakov, Anatoly
2018-10-04 13:35     ` Alejandro Lucero
2018-10-04 15:49       ` Burakov, Anatoly
2018-10-04 17:59         ` Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 4/5] net/nfp: check hugepages IOVAs based on DMA mask Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 5/5] net/nfp: support IOVA VA mode Alejandro Lucero
2018-10-02 16:33 ` [dpdk-dev] [PATCH v2 0/5] use IOVAs check based on DMA mask Alejandro Lucero
2018-10-02 21:21   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48acfd73-0a14-54c2-dfea-7e78235f6cf2@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).