From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D3DB0A0531; Tue, 4 Feb 2020 11:20:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5199B1C014; Tue, 4 Feb 2020 11:20:28 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id BF3EE1C00E for ; Tue, 4 Feb 2020 11:20:26 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2020 02:20:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,401,1574150400"; d="scan'208";a="249304027" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.124]) ([10.237.220.124]) by orsmga002.jf.intel.com with ESMTP; 04 Feb 2020 02:20:24 -0800 To: David Marchand , siddarth rai Cc: dev , julien.meunier@nokia.com References: From: "Burakov, Anatoly" Message-ID: <689bd647-e8f3-f6b6-da5e-4b03bf4f411e@intel.com> Date: Tue, 4 Feb 2020 10:20:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Big spike in DPDK VSZ 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 02-Feb-20 9:22 AM, David Marchand wrote: > On Thu, Jan 30, 2020 at 8:48 AM siddarth rai 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