DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Francesco <francesco.montorsi@gmail.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] very high VIRT memory usage
Date: Tue, 9 Jun 2020 13:46:27 +0100	[thread overview]
Message-ID: <c4b9a3d1-5ff8-6061-11c8-27caac830138@intel.com> (raw)
In-Reply-To: <CAKW0qihgw4mWJ6LWPG3DMHY-K6fTVoswK9UOEhKeceBG6Ph8qg@mail.gmail.com>

On 08-Jun-20 12:03 PM, Francesco wrote:
> Hi all,
> I upgraded an old DPDK-based app which was using DPDK 17.11 to latest DPDK
> 20.05 and I noticed that if I look  at "top" I see that the VIRT memory
> taken by my application is now 256.1GB while before it was <1GB.
> 
> I've seen this same behavior with also "testpmd" example... is this a known
> issue with latest DPDK versions?
> Can I tweak some setting to have VIRT memory usage more or less similar to
> RSS ?
> 
> I forgot to add I'm working on Linux, Centos7
> 
> Thanks,
> Francesco Montorsi
> 

There was a discussion on this not too long ago, but i can't seem to 
find it for some reason. Anyway, long story short, that's not a bug, 
that's by design.

Since 18.11 (or 18.05 to be precise), there is a new memory subsystem in 
DPDK that allows growing and shrinking DPDK memory usage at runtime. 
That means, you can start with zero hugepages preallocated, and then 
allocate as you go, letting the memory subsystem decide how much memory 
you need.

The catch is that all of this hugepage memory is allocated into 
somewhere, some virtual address space. And *that* address space is 
preallocated at startup, to allow for secondary processes to duplicate 
primary process's address space exactly, and allow dynamic allocation of 
*shared* memory at runtime.

This memory will show up in top et al. but the truth is, it's zero cost, 
because it's anonymous memory. It isn't actually taking up any RAM. It 
will show up in dumps (20.05 has already fixed that issue, and the fixes 
will probably be backported to stable, including 18.11), so unless you 
have a very specific problem, i don't think that's anything you should 
be concerned about.

-- 
Thanks,
Anatoly

  reply	other threads:[~2020-06-09 12:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 11:03 Francesco
2020-06-09 12:46 ` Burakov, Anatoly [this message]
2020-06-09 13:13   ` Ferruh Yigit
2020-06-09 13:39     ` Burakov, Anatoly
2020-06-09 15:35       ` Stephen Hemminger
2020-06-10  9:24         ` Burakov, Anatoly
2020-06-10 15:28           ` Stephen Hemminger
2020-06-10 15:44             ` Burakov, Anatoly
2020-06-09 19:40   ` Francesco
2020-06-10  9:24     ` Burakov, Anatoly
2020-06-10 10:14       ` Francesco
2020-06-10 11:07         ` Burakov, Anatoly

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=c4b9a3d1-5ff8-6061-11c8-27caac830138@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=francesco.montorsi@gmail.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).