From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 8E63C3237; Mon, 12 Nov 2018 20:31:47 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 05A1440051; Mon, 12 Nov 2018 20:31:47 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E394540050; Mon, 12 Nov 2018 20:31:46 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-59-122.mobileonline.telia.com [90.232.59.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 20D6E4004D; Mon, 12 Nov 2018 20:31:44 +0100 (CET) To: bugzilla@dpdk.org, dev@dpdk.org References: From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Cc: vipin.varghese@intel.com Message-ID: <9239c635-8d5c-f5cf-8a2e-c4df7e09bc2b@ericsson.com> Date: Mon, 12 Nov 2018 20:31:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [Bug 106] running dpdk-procinfo or any secondary leading to system memory exhaustion X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 19:31:47 -0000 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.