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 9F56DA051F; Wed, 10 Jun 2020 17:29:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1B8C61BED9; Wed, 10 Jun 2020 17:29:06 +0200 (CEST) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by dpdk.org (Postfix) with ESMTP id 6CB861BEB7 for ; Wed, 10 Jun 2020 17:29:04 +0200 (CEST) Received: by mail-pf1-f179.google.com with SMTP id b201so1263599pfb.0 for ; Wed, 10 Jun 2020 08:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=u+Cww8WVGIl0JS8zkjkvAZkIOzSLo3nAvkkj91i5h1o=; b=gZK4YZJlm7InKE/t/0hUK+RGONToZQLRW33k7VjzrgrzRwHGT1x8BwNzaZGZNFkeUa TmPrl+9bTjDgatOxKcG2eKRTp9DCM5NFTEhFxxgcT3868p0FFtza750IVALXATIspfA5 D5dDllUB/S5nMXZ6d5qCH45TgwaKRkQHZC46Cnlqf00/8AvJKYxeSgML5L57wlF5uAu7 eqvllFJrId+aB1jKHiS3vFHG2ZoOnHU9qo5h2UGE1VoKJQsxqFG1jdN5o10fCs0j6IZV YXYU++reOSuSM2Raw982KnIjvGmqy15vazxvB3f76cQ4y4pPg33uZcoon4UDaGdHJ54G gOpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=u+Cww8WVGIl0JS8zkjkvAZkIOzSLo3nAvkkj91i5h1o=; b=c9nIgAb19NgLdHFz8ar7UsZXWt5+C3YSlXfRmn3u/xN10gkd7tKYgg+Ibt/mRWZAYu 7KZZEt5S8NHfRg9FIp3zEH615t6X4jQo+Mf4YmZwHSXryH2uoPazegEH5xnPAM+CLu6O rcII/E/CuktJ3PFRueyhEphsbctq/rXhk+XOW6hzRuhQCGISgEx4VYE1ug38zozM+7lT d7Z/C5rKRYHDIIoNA1gEzPLZwM7b/a9BcjF87hjgU5ZzpaYtkLxWEKELVBmHYZ/IS0hB PXjyUNET6PcKXNmiI/HnbqcfLGTXTxL6w6BxhfFwyDUw5PYiBVoLTjDZh0q7VgvNImcI 8xPQ== X-Gm-Message-State: AOAM533ZL+j5/bfVonGEo9C2wOvhqU+F168IRrvxIIK2fKCLAwJ8o6h8 eVYGzAb1YQkGkFMZa9KSucZEQA== X-Google-Smtp-Source: ABdhPJw1W1vwHvXA5V/hU0e8zLtaiolBrfOwSJejB0UJAu3ez/DLoRG/re2KhPorCAUgcFPH53D2LQ== X-Received: by 2002:a63:fa4d:: with SMTP id g13mr3150347pgk.26.1591802943201; Wed, 10 Jun 2020 08:29:03 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id h17sm249671pfo.168.2020.06.10.08.29.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 08:29:02 -0700 (PDT) Date: Wed, 10 Jun 2020 08:28:54 -0700 From: Stephen Hemminger To: "Burakov, Anatoly" Cc: Ferruh Yigit , Francesco , dev@dpdk.org Message-ID: <20200610082854.381f68cb@hermes.lan> In-Reply-To: References: <575e70e0-0e56-ed43-0411-df6215b1758f@intel.com> <20200609083510.5c099744@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] very high VIRT memory usage 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 Wed, 10 Jun 2020 10:24:44 +0100 "Burakov, Anatoly" wrote: > On 09-Jun-20 4:35 PM, Stephen Hemminger wrote: > > On Tue, 9 Jun 2020 14:39:54 +0100 > > "Burakov, Anatoly" wrote: > > > >> On 09-Jun-20 2:13 PM, Ferruh Yigit wrote: > >>> On 6/9/2020 1:46 PM, Burakov, Anatoly wrote: > >>>> On 08-Jun-20 12:03 PM, Francesco wrote: > >>>>> Hi all, > >>>>> I upgraded an old DPDK-based app which was using DPDK 17.11 to latest DPDK > >>>>> 20.05 and I noticed that if I look at "top" I see that the VIRT memory > >>>>> taken by my application is now 256.1GB while before it was <1GB. > >>>>> > >>>>> I've seen this same behavior with also "testpmd" example... is this a known > >>>>> issue with latest DPDK versions? > >>>>> Can I tweak some setting to have VIRT memory usage more or less similar to > >>>>> RSS ? > >>>>> > >>>>> I forgot to add I'm working on Linux, Centos7 > >>>>> > >>>>> Thanks, > >>>>> Francesco Montorsi > >>>>> > >>>> > >>>> There was a discussion on this not too long ago, but i can't seem to > >>>> find it for some reason. > >>> > >>> Can it be "Big spike in DPDK VSZ" ? > >>> http://inbox.dpdk.org/dev/CAGxAMwD6Wtfi=C2Txwjfk0zhFvRzeqBu7mFfE8ayh=EJi2aU-A@mail.gmail.com/#t > >>> > >> > >> Yes, that's the one, thanks Ferruh :) > >> > >>>> Anyway, long story short, that's not a bug, > >>>> that's by design. > >>>> > >>>> Since 18.11 (or 18.05 to be precise), there is a new memory subsystem in > >>>> DPDK that allows growing and shrinking DPDK memory usage at runtime. > >>>> That means, you can start with zero hugepages preallocated, and then > >>>> allocate as you go, letting the memory subsystem decide how much memory > >>>> you need. > >>>> > >>>> The catch is that all of this hugepage memory is allocated into > >>>> somewhere, some virtual address space. And *that* address space is > >>>> preallocated at startup, to allow for secondary processes to duplicate > >>>> primary process's address space exactly, and allow dynamic allocation of > >>>> *shared* memory at runtime. > >>>> > >>>> This memory will show up in top et al. but the truth is, it's zero cost, > >>>> because it's anonymous memory. It isn't actually taking up any RAM. It > >>>> will show up in dumps (20.05 has already fixed that issue, and the fixes > >>>> will probably be backported to stable, including 18.11), so unless you > >>>> have a very specific problem, i don't think that's anything you should > >>>> be concerned about. > > > > The one concern is for cases like cgroup memory accounting thinking > > the process is huge and OOM killing it. > > > > Is there any way to know the *actual* memory usage of the process (i.e. > not including anonymous memory)? > Huge pages do not count against the normal memory in cgroup. There is a separate hugeTLB controller that limits that.