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 508A1C433EF for ; Tue, 24 May 2022 22:32:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A92728D0003; Tue, 24 May 2022 18:32:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A1EBE8D0001; Tue, 24 May 2022 18:32:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E4828D0003; Tue, 24 May 2022 18:32:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7D2888D0001 for ; Tue, 24 May 2022 18:32:30 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 4977180AC5 for ; Tue, 24 May 2022 22:32:30 +0000 (UTC) X-FDA: 79502086860.20.2BB34AF Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf01.hostedemail.com (Postfix) with ESMTP id 9153240035 for ; Tue, 24 May 2022 22:32:26 +0000 (UTC) Received: by mail-wr1-f46.google.com with SMTP id t6so27680728wra.4 for ; Tue, 24 May 2022 15:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/hjeyXIou+bR7sgCBUUS9KBiw7ITkpAtyGQPK8WkjHQ=; b=E47CS0uk7HJ3B0+amVIKreQyHTGL6Id/MNM0NxjP7X6opvCgl1WcdBa5SnwKc3EDWw V2RSBPZ5PBv0+cdx0NAoNLXYDyjDup9mou8/UiOBU++4DVMVZrHzrWd+ZVhZFW2K8uMW p9b4jxU7DGV0i8n8hpbveKXjRPZjF7JZfelsg33lCxe6KvbM/3Kw2gy36RExYeMQcSnp QyMMPOr6T3TA59Xk7ew90wKydoDBGM28Fu7tgOmM6JcjUpxvmSbhb9njgSwtUUkrwV/Z SDvlO42njKkIejaVhIiCDGW4sF9Mf28i9mQR4sp9xyvJ2C1xtsrbm5Tfz8hGqHkzJQq/ IEHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/hjeyXIou+bR7sgCBUUS9KBiw7ITkpAtyGQPK8WkjHQ=; b=5jUN3RYa0Qetxms+juhUU0+NzSNoRYH3r7c9bdQvhK71z+N6L507ht+41iQdfA6uvo 2Kl4MQSo+LwR2yPUUghKnDA3u4c5dHLPAnn8AmmsoqCMo5RSSIdcp0Q0Upn7/UcCVIA6 gASQHwurc8HjTo3KzHHxxXo+F4W6htzNSYYooJ+KPebrPikCCX/KFNGtfSJeIjZD5Bi9 1phx4eZuLthmrZWAHTFpLs8DDKZ0gJsBa3bxI4v8Ot5Tnn+hYamm1HVS9vBpephgKGp7 rEENDbI3LhDHfM0eBQnDAayJ/qZ47qjfQtZhdk93JIjvbyLaskzJ+yNcuRWQs8DlaEne aXIw== X-Gm-Message-State: AOAM532fkbQWVtrp3lGR0pmk2KjsAgxplCKJ/RH5VBRF7psrpbkzaV5E GaId33IleD5FWDxK8xi4GJ/JYIMkhc/048iosFoojw== X-Google-Smtp-Source: ABdhPJxT4ExN63oIrXSw4yucGOE3FdTxLSSWhIsKQP4q3l+uXQdQtcsiB0ShXvD15pANNDgeH4cCwpElZhKEPpNgNxo= X-Received: by 2002:adf:fb05:0:b0:20a:e113:8f3f with SMTP id c5-20020adffb05000000b0020ae1138f3fmr25324902wrr.534.1653431548193; Tue, 24 May 2022 15:32:28 -0700 (PDT) MIME-Version: 1.0 References: <20220429201131.3397875-1-yosryahmed@google.com> <20220429201131.3397875-2-yosryahmed@google.com> <87ilqoi77b.wl-maz@kernel.org> In-Reply-To: From: Yosry Ahmed Date: Tue, 24 May 2022 15:31:52 -0700 Message-ID: Subject: Re: [PATCH v4 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses. To: Johannes Weiner 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 Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=E47CS0uk; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9153240035 X-Stat-Signature: 3gjpizpnczj1q5ex3jpzoidfowkazzs1 X-HE-Tag: 1653431546-882168 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 Fri, May 20, 2022 at 7:39 AM Johannes Weiner wrote: > > On Thu, May 19, 2022 at 06:56:54PM -0700, Yosry Ahmed wrote: > > On Fri, May 13, 2022 at 10:14 AM Shakeel Butt wrote: > > > > > > On Fri, May 13, 2022 at 9:12 AM Sean Christopherson wrote: > > > > > > > [...] > > > > > > > > It was mostly an honest question, I too am trying to understand what userspace > > > > wants to do with this information. I was/am also trying to understand the benefits > > > > of doing the tracking through page_state and not a dedicated KVM stat. E.g. KVM > > > > already has specific stats for the number of leaf pages mapped into a VM, why not > > > > do the same for non-leaf pages? > > > > > > Let me answer why a more general stat is useful and the potential > > > userspace reaction: > > > > > > For a memory type which is significant enough, it is useful to expose > > > it in the general interfaces, so that the general data/stat collection > > > infra can collect them instead of having workload dependent stat > > > collectors. In addition, not necessarily that stat has to have a > > > userspace reaction in an online fashion. We do collect stats for > > > offline analysis which greatly influence the priority order of > > > optimization workitems. > > > > > > Next the question is do we really need a separate stat item > > > (secondary_pagetable instead of just plain pagetable) exposed in the > > > stable API? To me secondary_pagetable is general (not kvm specific) > > > enough and can be significant, so having a separate dedicated stat > > > should be ok. Though I am ok with lump it with pagetable stat for now > > > but we do want it to be accounted somewhere. > > > > Any thoughts on this? Johannes? > > 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 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.