DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Francesco <francesco.montorsi@gmail.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] very high VIRT memory usage
Date: Wed, 10 Jun 2020 12:07:32 +0100	[thread overview]
Message-ID: <942076c2-770a-3f8c-6f40-d18b908acb7e@intel.com> (raw)
In-Reply-To: <CAKW0qihETAVmAh9Uq_1jLVjnLvauETZwpSNGw60PXB_M-EK0CA@mail.gmail.com>

On 10-Jun-20 11:14 AM, Francesco wrote:
> Hi Anatoly
> 
> Il giorno mer 10 giu 2020 alle ore 11:24 Burakov, Anatoly 
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> ha scritto:
> 
>     On 09-Jun-20 8:40 PM, Francesco wrote:
>      > Hi Anatoly,
>      >
>      > Thanks a lot for the detailed response!
>      > Good to know anyway there's a "fix" already done in 20.05... also
>      > because I'm not interested in supporting secondary processes or
>     having
>      > shared memory...
>      >
>      > Looking forward for the backports in stable branches then!
>      >
>      > Thanks!
>      > Francesco
>      >
> 
>     Hi Francesco,
> 
>     Just to be clear - the "fix" i'm talking about is not about using less
>     memory - it's about not including this memory in core dumps. The memory
>     amounts used will stay the same (i.e. you'll still see the ~256GB used
>     each time you run DPDK).
> 
> 
> Ouch ok I see.
> My issue is that I have tools that look at the health of my server and 
> will report this high VIRT memory usage as anomalous - I guess I will 
> have to work around them some way.
> 
> Thanks for the clarification
> 
> Francesco
> 

Yep. Like i said earlier, this is a design decision. I understand that 
not everyone wants or needs secondary process support, but we have to 
have defaults that cover the most amount of use cases. Plus, it make 
internals very complex if we had two different init (and runtime!) paths 
for DPDK with and without secondary process support. So, there's little 
that can be done about that, short of lowering that limit at compile 
time. You can use the CONFIG_RTE_MAX_MEM_MB and similar options in the 
DPDK config file, but if you got your DPDK from a distro, you're out of 
luck, i'm afraid.

-- 
Thanks,
Anatoly

      reply	other threads:[~2020-06-10 11:07 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
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 [this message]

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=942076c2-770a-3f8c-6f40-d18b908acb7e@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).