Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp453399ioo; Sat, 21 May 2022 04:14:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2vBdWaw7SrL9mgZhsKvxqFTywNH4kzm1LJ5F9BoxBcRUriTNL+vM5rxdODeDCcfg7ZNxq X-Received: by 2002:aa7:d484:0:b0:42a:ae08:d18a with SMTP id b4-20020aa7d484000000b0042aae08d18amr15324528edr.422.1653131682037; Sat, 21 May 2022 04:14:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653131682; cv=none; d=google.com; s=arc-20160816; b=U/+OwCEChOF7dl4LutgQ2FkarEawDOfAGgOC/QqsfhrzgxFrTxfL2G6FJzX8jhhpyX GhFhaLhF/7KWI44k0uy9n5wnz2cXN/GRLK1HQwHMQlM33y4ImuEKJZb4Geh5XMtAYwlO CIj7WtjmIYKuI4/X8BlOneyqQ6J/EuhiEEX1DBPqdBCLJ341AywURVrNHbRRUT1AuAVg pIdUb5MEXvdY/L+yDev3w2BF+TgWxJE83sdTqgoKx2fEaIQ/M27dEECx6uFKuU0Li0ti h0Upi+In75NF/4/IdOchscafWkTFnm0B3HuyIWtvkzq/LsQg312LOnOMqnr75J74X6Dm qugA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=h/NS3+bOivmdn/Z8oAqTayRG5MjC4lANEwiPrpSX5IA=; b=VrRKTdodMwruPZpkeIdCjWuCF73LjvlP/tQHzT7YageKazLYpnG7NKF23IEE7NKaub bxHPCEqTfYLhR0x6H28G7AtENdxWO0gI/8j/+UisvJhU3Qx1Ealed4QFcpj6jEuxT9t2 qJ9qbP7ZFuCDf0Cgeqt71CesOXcPNpLDtqZn/wpt9kfaS72ZUHntuJIIUY3T2NstWFwq WKsOEb5m9z2BDN1ZQzZv6YXN6Zbi75+5iVQxhLv4D0/P7/+oULhANZM2kBcM/+Z202K9 46V8pTFwO15HCdfyCmr8P4miWkWvjzqGKI1bxrIlH5eEpbVpaEQGuL29hb2q6AspPq9D dSow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=lC1A71c8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q6-20020a056402518600b0042af7dbbff4si7666482edd.235.2022.05.21.04.14.16; Sat, 21 May 2022 04:14:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=lC1A71c8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239198AbiETB5i (ORCPT + 99 others); Thu, 19 May 2022 21:57:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230474AbiETB5g (ORCPT ); Thu, 19 May 2022 21:57:36 -0400 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A4A1EBE88 for ; Thu, 19 May 2022 18:57:32 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id s28so9428849wrb.7 for ; Thu, 19 May 2022 18:57:32 -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=h/NS3+bOivmdn/Z8oAqTayRG5MjC4lANEwiPrpSX5IA=; b=lC1A71c86K3b210P5MINYKI+0nEPTtRGK3LeWj2Npew4lX9mJGgrpWWegiuNtMwlJO P1IlUwgqu95jwD3J+mnRGelGqXz+HoaJ7VCJk9hhvvF66jPz+hrvF0dmKSe2LLL2Vgq/ rwXqca2l71+mfz5tl8pRhTv4LCsg9QGocKsxdwCfWXbGVabJpfgNFG9+rBVSpj/uhude 6hLQ+JpxChsTxgZBARTq2zFr80q+S2jttKKsRPO0P7o9moE/Iyx8K/oNzwHCGA7J5UxE CJjZ0hW/O6s0vTeoubWTNpA5gAfGug3OjBmx35+8T9dkzXFSpzM7/kEn0mCCEAR9GuP4 zRlQ== 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=h/NS3+bOivmdn/Z8oAqTayRG5MjC4lANEwiPrpSX5IA=; b=M/nMMtY6SFgcUxkY4QGVE+/CQeWWzMj2LULuD9oJqlnM+b2/Sgvg0LFtcDt4vFExR4 Q1iaAimU30RuugbzI9+buAHelDlFDj9JokEo4bmVh5QqbaXzeNUT73j+XA1Fy34WkL7i oZDa7UwhS3Ny0sCvjdGtmFr+8ejyr8tsVebmx2ymozoKsvnIaGdub8pnxZhyhQ/Gs93F Vx3DfA+bL+XXigrk6LvI9iKdU3ytBCAgxi14jPcZMNsz+NrvQMc381FNWkk4bbml0VCF 1jw7G7A+9pans70+F93Wy2oo+sKkc0CY83RUg/ru+ecN5lDSu97GMVftmz/aWr88EVno Ul7g== X-Gm-Message-State: AOAM5332uuCCyh+7y5hsOIb6/dzGbOWL1UitHxmV9bdIaf9Ej9psEVhB eH39LToM6mq4RA+bzviG4F8l6TBs6DivxhkxklkEkw== X-Received: by 2002:adf:f042:0:b0:20e:5be7:f473 with SMTP id t2-20020adff042000000b0020e5be7f473mr6249346wro.80.1653011850753; Thu, 19 May 2022 18:57:30 -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: Thu, 19 May 2022 18:56:54 -0700 Message-ID: Subject: Re: [PATCH v4 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses. To: Shakeel Butt Cc: Sean Christopherson , Johannes Weiner , 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" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?