From: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
To: bugzilla@dpdk.org, dev@dpdk.org
Cc: vipin.varghese@intel.com
Subject: Re: [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion
Date: Mon, 12 Nov 2018 20:31:43 +0100 [thread overview]
Message-ID: <9239c635-8d5c-f5cf-8a2e-c4df7e09bc2b@ericsson.com> (raw)
In-Reply-To: <bug-106-3@http.bugs.dpdk.org/>
On 2018-11-12 11:44, bugzilla@dpdk.org wrote:
> https://bugs.dpdk.org/show_bug.cgi?id=106
>
> Bug ID: 106
> Summary: running dpdk-procinfo or any secondary leading to
> system memory exhaustion
> Product: DPDK
> Version: 18.05
> Hardware: x86
> OS: Linux
> Status: CONFIRMED
> Severity: critical
> Priority: Normal
> Component: core
> Assignee: dev@dpdk.org
> Reporter: vipin.varghese@intel.com
> Target Milestone: ---
>
> Issue: Running dpdk secondary instance in multiple iterations leads to memory
> exhaustion
>
Exhaustion, meaning the kernel eventually - given enough iterations of
the test program - invoke the OOM handler (i.e. crash)?
>
> Run script:
> #!/bin/sh
>
> ./build/app/test
> ret=$?
>
> while [ $ret -eq 0 ]
> do
> sync; echo 3 > /proc/sys/vm/drop_caches
> ./build/app/test
> ret=$?
> echo "ret ---------------- $ret"
> done
>
An application causing the kernel to cache more pages wouldn't normally
be considered to be leaking memory, if those pages are not dirty. If
"echo 3 > /proc/sys/vm/drop_caches" frees the memory "leaked", it wasn't
leaked. That holds true even for system with swapping enabled.
You can't use MemFree (in /proc/meminfo) or similar as an indication how
much memory is actually available to applications, would they need it.
Pages that "echo 3 > /proc/sys/vm/drop_caches" frees, would also be free
would the system come under memory pressure. A drop in MemAvailable is a
better indication of applications' using more memory.
find $HOME -type f | xargs cat >/dev/null
For example, find+cat above aren't leaking memory, even if the pipeline
likely causes MemFree to go down.
Anyway. If the answer to my first question is "the kernel crashes", you
can ignore all this.
next prev parent reply other threads:[~2018-11-12 19:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-12 10:44 bugzilla
2018-11-12 19:31 ` Mattias Rönnblom [this message]
2018-11-13 17:03 ` bugzilla
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=9239c635-8d5c-f5cf-8a2e-c4df7e09bc2b@ericsson.com \
--to=mattias.ronnblom@ericsson.com \
--cc=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
--cc=vipin.varghese@intel.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).