All of lore.kernel.org
 help / color / mirror / Atom feed
From: Walker, Benjamin <benjamin.walker at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] No free hugepages reported in hugepages
Date: Wed, 19 Jul 2017 22:12:01 +0000	[thread overview]
Message-ID: <1500502320.3169.3.camel@intel.com> (raw)
In-Reply-To: 528eb21edefd74f6dca93c727c3dab1f@mail.gmail.com

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On Wed, 2017-07-19 at 14:02 +0530, Oza Oza wrote:
> Hi All,
>  
> 1)      DPDK fails if huge-pages are not reserved. But should not it fall back
> to regular 4k pages ?

Hugepages are not just used for efficiency reasons - they're used as a way to
get DMA safe memory in user space. I wrote an extensive overview of the
challenges in this area here:

http://www.spdk.io/doc/memory.html


> 2)      And how user space should know the requirement of number of hug pages
> before-hand ?
> a.      Rather should it always be reserved before-hand in the system?, with
> that we might waste some.

I agree that this is a real usability challenge and a more dynamic memory
allocator for hugepages would be a great leap forward for both DPDK and SPDK.
Until we get to that point, you have to pre-reserve pages and you'll probably
waste some amount of memory.

>  
>  
>  
> Regards,
> Oza.
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3274 bytes --]

             reply	other threads:[~2017-07-19 22:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-19 22:12 Walker, Benjamin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-07-19  8:32 [SPDK] No free hugepages reported in hugepages Oza Oza

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=1500502320.3169.3.camel@intel.com \
    --to=spdk@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.