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 990BDA0531; Tue, 4 Feb 2020 11:23:50 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F15621C000; Tue, 4 Feb 2020 11:23:49 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 015C41BFA8 for ; Tue, 4 Feb 2020 11:23:47 +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 fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2020 02:23:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,401,1574150400"; d="scan'208";a="249304860" 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:23:45 -0800 To: David Marchand , siddarth rai Cc: dev References: From: "Burakov, Anatoly" Message-ID: <6cebb805-91a3-c074-2380-8ec90ed6c132@intel.com> Date: Tue, 4 Feb 2020 10:23:44 +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 30-Jan-20 8:51 AM, David Marchand wrote: > On Thu, Jan 30, 2020 at 8:48 AM siddarth rai wrote: >> 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 ? > > *Disclaimer* I don't know the arcanes of the mem subsystem. > > I suppose this is due to the memory allocator in dpdk that reserves > unused virtual space (for memory hotplug + multiprocess). Yes, that's correct. In order to guarantee memory reservation succeeding at all times, we need to reserve all possible memory in advance. Otherwise we may end up in a situation where primary process has allocated a page, but the secondary can't map it because the address space is already occupied by something else. > > If this is the case, maybe we could do something to enhance the > situation for applications that won't care about multiprocess. > Like inform dpdk that the application won't use multiprocess and skip > those reservations. You're welcome to try this, but i assure you, avoiding these reservations is a lot of work, because you'd be adding a yet another path to an already overly complex allocator :) > > Or another idea would be to limit those reservations to what is passed > via --socket-limit. > > Anatoly? I have a patchset in the works that does this and was planning to submit it to 19.08, but things got in the way and it's still sitting there collecting bit rot. This may be reason enough to resurrect it and finish it up :) > > > > -- > David Marchand > -- Thanks, Anatoly