From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: David Marchand <david.marchand@redhat.com>,
siddarth rai <siddsr@gmail.com>
Cc: dev <dev@dpdk.org>, julien.meunier@nokia.com
Subject: Re: [dpdk-dev] Big spike in DPDK VSZ
Date: Tue, 4 Feb 2020 10:20:23 +0000 [thread overview]
Message-ID: <689bd647-e8f3-f6b6-da5e-4b03bf4f411e@intel.com> (raw)
In-Reply-To: <CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com>
On 02-Feb-20 9:22 AM, David Marchand wrote:
> On Thu, Jan 30, 2020 at 8:48 AM siddarth rai <siddsr@gmail.com> wrote:
>>
>> Hi,
>>
>> I have been using DPDK 19.08 and I notice the process VSZ is huge.
>>
>> I tried running the test PMD. It takes 64G VSZ and if I use the
>> '--in-memory' option it takes up to 188G.
>>
>> Is there anyway to disable allocation of such huge VSZ in DPDK ?
>> This is resulting in huge core files and I suspect that the problem will
>> compound on multi-NUMA machines.
>
> For this particular issue, it might be interesting to look at madvise stuff:
>
> MADV_DONTDUMP (since Linux 3.4)
> Exclude from a core dump those pages in the range
> specified by addr and length. This is useful in applications that
> have large areas of memory that are known not to be useful in a core
> dump.
> The effect of MADV_DONTDUMP takes precedence over the
> bit mask that is set via the /proc/PID/coredump_filter file (see
> core(5)).
>
> (FreeBSD seems to have a MADV_NOCORE flag too).
>
>
This is perhaps the best option, as this problem isn't going away any
time soon. We've had this problem on FreeBSD already, which is why
--no-mlockall exists in testpmd and is default on FreeBSD, and which is
why we advise all our validation teams to disable core dumping on
FreeBSD when running DPDK. If a similar (but perhaps less invasive)
solution exists for Linux, that's great.
--
Thanks,
Anatoly
prev parent reply other threads:[~2020-02-04 10:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 7:48 siddarth rai
2020-01-30 8:51 ` David Marchand
2020-01-30 10:47 ` siddarth rai
2020-01-30 13:15 ` Meunier, Julien (Nokia - FR/Paris-Saclay)
2020-01-31 12:14 ` siddarth rai
2020-03-10 15:26 ` David Marchand
2020-02-04 10:23 ` Burakov, Anatoly
2020-02-04 10:55 ` siddarth rai
2020-02-04 11:13 ` Burakov, Anatoly
2020-02-04 11:57 ` siddarth rai
2020-02-04 12:07 ` siddarth rai
2020-02-04 16:18 ` Burakov, Anatoly
2020-02-11 8:11 ` David Marchand
2020-02-11 10:28 ` Burakov, Anatoly
2020-02-02 9:22 ` David Marchand
2020-02-04 10:20 ` 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=689bd647-e8f3-f6b6-da5e-4b03bf4f411e@intel.com \
--to=anatoly.burakov@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=julien.meunier@nokia.com \
--cc=siddsr@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).