DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jeff Shaw <jeffrey.b.shaw@intel.com>
To: Matt Laswell <laswell@infiniteio.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Ability to/impact of running with smaller page sizes
Date: Mon, 30 Jun 2014 16:42:29 -0700	[thread overview]
Message-ID: <20140630234229.GA19646@plxv1142.pdx.intel.com> (raw)
In-Reply-To: <CA+GnqAo_mytb7A=HQ7BY+XRyczazd4fpt_wTvj_R8-Zde3wGhw@mail.gmail.com>

Hi Matt,

On Mon, Jun 30, 2014 at 05:43:39PM -0500, Matt Laswell wrote:
> Hey Folks,
> 
> In my application, I'm seeing some design considerations in a project I'm
> working on that push me towards the use of smaller memory page sizes.  I'm
> curious - is it possible in practical terms to run DPDK without hugepages?

Yes, but I do not believe an implementation exists.

>  If so, does anybody have any practical experience (or a
> back-of-the-envelop estimate) of how badly such a configuration would hurt
> performance?  For sake of argument, assume that virtually all of the memory
> being used is in pre-allocated mempools (e.g lots of rte_mempool_create(),
> very little rte_malloc().
> 

It is possible, though not recommended if you want "good performance", to use
smaller memory page sizes.  Poor performance results from penalties incurred
due to DTLB misses.  Please consider the following example.
 
An application pre-allocates several thousand buffers to use for packet
reception and transmission using 4KB pages.  Each buffer contains 2KB worth
of data space, or enough to store the typical maximum Ethernet frame size. 
Since the page size is only 4KB, each DTLB entry can cache a maximum of two
packet buffer address translations.  If the first level DTLB has, for
instance, 64 x 4KB entries, you would only be able to cache about 128 address
translations at any given time (+1,024 if you include the second level DTLB). 
With 32 x 2MB entries, each DTLB entry can cache address translations for 32K
packet buffers at any given time.
 
If you believe that your application performance will be negatively impacted
by latencies incurred due to DTLB misses, it is recommended to take steps
which would maximize the DTLB hit rate.
 
Of course, you will not know how this impacts performance for you application
unless it is tried under realistic conditions.  If you end up doing so, could
you please update the list?


Thanks,
Jeff

  reply	other threads:[~2014-06-30 23:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 22:43 Matt Laswell
2014-06-30 23:42 ` Jeff Shaw [this message]
2014-07-01  8:56   ` Liu, Jijiang
2014-07-01 11:06     ` Ananyev, Konstantin
2014-07-01 11:51 ` Burakov, Anatoly
2014-07-01 12:36   ` Matt Laswell

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=20140630234229.GA19646@plxv1142.pdx.intel.com \
    --to=jeffrey.b.shaw@intel.com \
    --cc=dev@dpdk.org \
    --cc=laswell@infiniteio.com \
    /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).