From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C182C433F5 for ; Wed, 25 May 2022 11:56:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9ABD8D0003; Wed, 25 May 2022 07:56:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D46358D0002; Wed, 25 May 2022 07:56:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE8958D0003; Wed, 25 May 2022 07:56:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B0E598D0002 for ; Wed, 25 May 2022 07:56:46 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 82C7F21237 for ; Wed, 25 May 2022 11:56:46 +0000 (UTC) X-FDA: 79504113612.28.8001074 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf30.hostedemail.com (Postfix) with ESMTP id B74218003B for ; Wed, 25 May 2022 11:56:16 +0000 (UTC) Received: by mail-qt1-f180.google.com with SMTP id m13so10730403qtx.0 for ; Wed, 25 May 2022 04:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lEk6v60gkjFT68Gj4bJNaNs7k2gNzwxPhiEY5nNwaQQ=; b=XXcCcSNfXU4ZumvEofzKMhDBd7cN4uUTScIpzCQEM+hzYYKUfsKNiF4P7UVF51FKtd 5RMh2GAnDESjADbuXOd1AqGedzaXh0w5A9T12BqTWJPxR4mUsbYzVpqI1DeLqcj+jRCv g4Mbz8Isqpigexjq2xgBfxvEZ6XOCfbhrEWV/D3mKfrw49MZYSOCSMLcFNY4bPWoBIIQ R5QYWFwAz8og1bHFYOMrTQ4s+e/PEPEozRRHKxlX3pJQbF9dxpvlI9pbg9wJj7C5geki qkYRTvMTxuO0dTaFgb5ZebuX4LpE/ZIxHighxOWhBpx05saqXnbfuwd4MPhQ1tJOvxUj hZDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lEk6v60gkjFT68Gj4bJNaNs7k2gNzwxPhiEY5nNwaQQ=; b=3eSFAVVCTwmgnKPJJnOIuteZzaL1oK3d6mo2V5YoTkLts+3JZ04f1yO3VDqDv7d1J7 i1fjz3oEr/vLo0CMqcFqGVvp74Go3KgFP6/I693buMozmucKhVIeai9FGvHwAwq+iWGq 6M1O0o3LznEJiEhJ65IBfHHmGNDXZduq1Viwkk1sEcxeok+pt7SxDlzh6yUjiqAor/T5 sqfeP3AW7R6T6ozCSjcsHUSc08NnMlTlzylig6Gh74Gd9K6HvQGqKDQJQcBlTXpPYjzo OcZCV1/1GqatJBr/+mUQbX78dLnrn78VdPq3dqXXtJu5DeDsX6qq0bgw9xDQDg1rWZBV +okQ== X-Gm-Message-State: AOAM530UufoHfB/hFx8mLz7mSp4EQm3oMG27EKUF4N4xFQP49u4GO/C+ JLODvEWW9bPPIVTQWiwTfSic2Q== X-Google-Smtp-Source: ABdhPJwFHUkIBHNUiY22IoYqV5QV59CSwCqYRuCiU7sPHckigA3yOeAfSHjhUNo+n/aWFHPqKI7LJA== X-Received: by 2002:ac8:4e81:0:b0:2f9:34e4:8955 with SMTP id 1-20020ac84e81000000b002f934e48955mr11600672qtp.459.1653479804938; Wed, 25 May 2022 04:56:44 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:741f]) by smtp.gmail.com with ESMTPSA id m25-20020ac84459000000b002f94737333bsm1152559qtn.21.2022.05.25.04.56.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 May 2022 04:56:44 -0700 (PDT) Date: Wed, 25 May 2022 07:56:43 -0400 From: Johannes Weiner To: Yosry Ahmed Cc: Shakeel Butt , Sean Christopherson , Marc Zyngier , Tejun Heo , Zefan Li , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Andrew Morton , Michal Hocko , Roman Gushchin , Oliver Upton , Cgroups , Linux Kernel Mailing List , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux-MM Subject: Re: [PATCH v4 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses. Message-ID: References: <87ilqoi77b.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B74218003B X-Stat-Signature: 3ch93f9izi1ga9un8jx6awyfm9xd7twa Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=XXcCcSNf; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf30.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.180 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1653479776-750612 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, May 24, 2022 at 03:31:52PM -0700, Yosry Ahmed wrote: > On Fri, May 20, 2022 at 7:39 AM Johannes Weiner wrote: > > I agree that this memory should show up in vmstat/memory.stat in some > > form or another. > > > > The arguments on whether this should be part of NR_PAGETABLE or a > > separate entry seem a bit vague to me. I was hoping somebody more > > familiar with KVM could provide a better picture of memory consumption > > in that area. > > > > Sean had mentioned that these allocations already get tracked through > > GFP_KERNEL_ACCOUNT. That's good, but if they are significant enough to > > track, they should be represented in memory.stat in some form. Sean > > also pointed out though that those allocations tend to scale rather > > differently than the page tables, so it probably makes sense to keep > > those two things separate at least. > > > > Any thoughts on putting shadow page tables and iommu page tables into > > the existing NR_PAGETABLE item? If not, what are the cons? > > > > And creating (maybe later) a separate NR_VIRT for the other > > GPF_KERNEL_ACCOUNT allocations in kvm? > > I agree with Sean that a NR_VIRT stat would be inaccurate by omission, > unless we account for all KVM allocations under this stat. This might > be an unnecessary burden according to what Sean said, as most other > allocations scale linearly with the number of vCPUs or the memory > assigned to the VM. I think it's fine to table the addition of NR_VIRT for now. My conclusion from this discussion was just that if we do want to add more KVM-related allocation sites later on, they likely would be something separate and not share an item with the shadow tables. This simplifies the discussion around how to present the shadow tables. That said, stats can be incremental and still useful. memory.current itself lies by ommission. It's more important to catch what's of significance and allow users to narrow down pathological cases. > I don't have enough context to say whether we should piggyback KVM MMU > pages to the existing NR_PAGETABLE item, but from a high level it > seems like it would be more helpful if they are a separate stat. > Anyway, I am willing to go with whatever Sean thinks is best. Somebody should work this out and put it into a changelog. It's permanent ABI.