On 2018-11-12 11:44, bugzi...@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.vargh...@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.
