From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= <mattias.ronnblom@ericsson.com>
Subject: Re: [Bug 106] running dpdk-procinfo or any secondary
 leading to system memory exhaustion
Date: Mon, 12 Nov 2018 20:31:43 +0100
Message-ID: <9239c635-8d5c-f5cf-8a2e-c4df7e09bc2b@ericsson.com>
References: <bug-106-3@http.bugs.dpdk.org/>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: vipin.varghese@intel.com
To: bugzilla@dpdk.org, dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
In-Reply-To: <bug-106-3@http.bugs.dpdk.org/>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@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.