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 6DD05A0513; Tue, 9 Jun 2020 17:35:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 12CF52C60; Tue, 9 Jun 2020 17:35:22 +0200 (CEST) Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by dpdk.org (Postfix) with ESMTP id 18CA62C58 for ; Tue, 9 Jun 2020 17:35:20 +0200 (CEST) Received: by mail-pf1-f194.google.com with SMTP id j1so10067292pfe.4 for ; Tue, 09 Jun 2020 08:35:19 -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=zn0iaV6ykml5mvYHYOQZEDhie45SYSRaenP8AhiSl/Y=; b=NnYCqGXqbwAHzP7J+45RhtwhGU8lQmONwcEO3yjXMOhcBWovhofilydsSeymTpvDFA dsZ4Qlp0NDfoEZrH0ImKJjN9ZQ9QMdRx8tn742/4PDZmQij8Omq4Wk97TvYv1pHxNB8L LsDbdYwf17tDU175ZwyUwWnktdL3lrMNXhyicYHoY/ZZWiNRKYM/B2vWb6yLA7gSTtgU UR2Y6V9TV1mx8eRgD9OasloJHqwtN62DLuLWhlHJKl+JeIro61Q/ZKSlu3w4VyJCoNzH pTm8MjJAhAwVMJquF2CHu9Dssj7J4uNQZJyv31HfrhVhyn9bCvQFEl+frRFyZrQXIoOL S9MA== 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=zn0iaV6ykml5mvYHYOQZEDhie45SYSRaenP8AhiSl/Y=; b=NnocbQBulHhxjtdzbCU0qJGFdOu7/62eXDkJtjrR0BUphxrdvK4pDRW+zmWDoiM9Bd piESXtfYxvtj8ZKM+VqvTXjNwuc3MXRTbXJXT8dmDDcjTEW6OiGZrc+oB2/ofyQaJYhd MQg8JATbt9wV4ZPXvGo9Yoz1DXyuu8k2fpI4NcwIx0K6qPmZ0uI8k9IPYqQvzIOWU61G 5ApNrZ3ckPTKT401tmVaoN4TehsIfTWyyERyBW4/w2XRG0NRZuNkPpXPZiT73EV1tMYN Vvfne4LD6RQL0yxFNeDLfktakbyjdQnYc/UIS6kVD4JuF9tEGp2l6ACDCScd0ZNUh1iK d6DA== X-Gm-Message-State: AOAM530DeEgWR3Fp4MoV6+DJmaxKGrykz+ErfRXGUNHK8BVgNwyYT6g9 PeY9I6ngbzWc19Mms3xefB0rxw== X-Google-Smtp-Source: ABdhPJwpFcs927pJ5+yhYz0/lotYo5I+IfsBSz9l9z17G+/4Cye2DfB1BJQeRfqi7cnEJ2fwM2x7RA== X-Received: by 2002:a05:6a00:793:: with SMTP id g19mr25104128pfu.264.1591716918770; Tue, 09 Jun 2020 08:35:18 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 71sm10508573pfb.20.2020.06.09.08.35.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 08:35:18 -0700 (PDT) Date: Tue, 9 Jun 2020 08:35:10 -0700 From: Stephen Hemminger To: "Burakov, Anatoly" Cc: Ferruh Yigit , Francesco , dev@dpdk.org Message-ID: <20200609083510.5c099744@hermes.lan> In-Reply-To: References: <575e70e0-0e56-ed43-0411-df6215b1758f@intel.com> 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 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.