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 E4257A051C; Tue, 11 Feb 2020 09:11:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B70C42BD8; Tue, 11 Feb 2020 09:11:48 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id B48452BD5 for ; Tue, 11 Feb 2020 09:11:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581408706; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=weTe3NLG8ezBnAi6PTDDFXh7Kd8fakk2BU60KTHgmRU=; b=SRykpevTvOLxHC6oJXXB82ckWMQ5n92lwv7FGX3k7l+vilgN7u7zNPY23f8I7fTAIJFijn XyYSFMW+FS/CRC1FQfyWkCzxUiKYZPfyJ4vAOnS7ybSWj/m+X4pNNPMyZdbJPKOklrYpYf 0jhsNmFu84tdlgGVkkJ5MtxLwH+ja4k= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-234-FaD_kugDO5--wnZGgXRcQw-1; Tue, 11 Feb 2020 03:11:42 -0500 Received: by mail-vk1-f198.google.com with SMTP id k129so3120091vka.4 for ; Tue, 11 Feb 2020 00:11:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YLoVtSSbRwsdR8LDQBPvMvCDosrl6+D8pxND+0pSK2I=; b=EWIxH2PotmTnX6xqowo6SVBnjMbTdrP7f3eAt4/0PT1AxFkB4aspsrJiEQ3ixX1Ieo nTVPSkAOeFOLKSmhO7/2n3823gpohqHLJao5/7YbDj4c/OkCX6xZKNltuAEghJUmRegC zDp0J7w/NBxNETxYrZm8A6BjmgbGNGdIaydklnY11C8HMG3RzwDsshiQ5PYMOP+NrEIL 7odaUsF5BrRvUJUXknT5RB9TkDHtT2GjVjZgCQ5oMHfD9CWEBxs9BsEaXsuzZ9PeCg+W F6bhPS1dpMRra8I7MH6c6Qw0cpBtMWlfzucovRNngjouaroEeSQVUW0YrMVfLRjM3SEr HW7g== X-Gm-Message-State: APjAAAWNPJWWc4iM9PPRPogJgV1E3e1wLtOnFSIEEHSVBH46nLqTDZjE yeBqHgcg6R9MbexH73Fhpp44npl0li5Wm+iJKCdn1GfXR2e01PYGU17P2cNDayS6Jww/cZDUz4q esqdakDtOB7Jc6i2+LeM= X-Received: by 2002:a67:905:: with SMTP id 5mr8633785vsj.105.1581408702140; Tue, 11 Feb 2020 00:11:42 -0800 (PST) X-Google-Smtp-Source: APXvYqzxZv/axNwInTmZssHvRInpYFjMiFJnfJh301fRzdeEXus0yvipxF+LtKbe56C2o54hHnha2VQg+alzI2nzwRQ= X-Received: by 2002:a67:905:: with SMTP id 5mr8633771vsj.105.1581408701829; Tue, 11 Feb 2020 00:11:41 -0800 (PST) MIME-Version: 1.0 References: <6cebb805-91a3-c074-2380-8ec90ed6c132@intel.com> In-Reply-To: <6cebb805-91a3-c074-2380-8ec90ed6c132@intel.com> From: David Marchand Date: Tue, 11 Feb 2020 09:11:30 +0100 Message-ID: To: "Burakov, Anatoly" Cc: siddarth rai , dev X-MC-Unique: FaD_kugDO5--wnZGgXRcQw-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" Hello Anatoly, On Tue, Feb 4, 2020 at 11:23 AM Burakov, Anatoly wrote: > > 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 :) Went and looked at the EAL options we have. I understand that the --in-memory (essentially the --no-shconf functionality) option should be enough. I can see that Siddarth uses it. But the problem is that the memory allocator still reserves big va areas for memory hotplug. > > > > > 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 :) Does this patchset contain more than just taking --socket-limit into accoun= t? -- David Marchand