Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2016031ioo; Sat, 28 May 2022 02:16:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwz5BTiDJ3gNXW2/5IZmyHLxl1RK1SBL2xi77tb7Qui2jM09q7oqiGuE4/XEzZJ1SYr9Hjr X-Received: by 2002:a17:902:d4c2:b0:163:78db:cf99 with SMTP id o2-20020a170902d4c200b0016378dbcf99mr12085877plg.138.1653729409514; Sat, 28 May 2022 02:16:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653729409; cv=none; d=google.com; s=arc-20160816; b=TgVPmVH9dV6Qz2K9Kvj18TzcywoU5H5scmqqgjih1Smu+WP8V15eqJZANWQKDh+xVZ 3MwPR8W08ZKklGyBSzWk4v6QFy6agauFNTb1P/ljYTgEkTBWQJmSEmEnJHusLYmrw/mm S/Zed0gHO1RWK7QxoUoub44JdfRIfzv55jnwSHINuMzkGZqpXPoTmb8upf7dQHz10efy +yF+LyulmE36HXxMtrIX5k1LzE5LN9IAtJRLxHXRLD9/8l50hx0cbISeZ5aM8TXsjswN Dt6q59TnTJ5JpPXEskIqoUbovfceCZ2vmQ8LCb7jLrpXydeGZYZXZBzHMdt2Mg/ODrhV +/EA== 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=ZMRaR78nxxjwROTv5Xv0uCrlGpUNKsmrgGJVBdvr8Ow=; b=gaI0c1XjXxqvfEaf0G+Rxx3RsSM4Y1eWl3hqsAfTjUashhTtemkEyG3FQcP/nhccNK n5GENiZ+pTTEGC+uVzHry/XTR9MuoyFCMjIi481RiC1gX9K7Ge+++aoa0LDGmkl4zB78 WZae8Z2UDqEJJKzILWkUIGANB5/LuaFWcs48GxAunaKctdGnPpg8qn/H++hKjegnGJRE 0Twz3dJ2JNOkmwz+sFTBWtDgIObN8M4GY46cNyoUWv++YVKjzf8N9hBvI91ZNFCxWMA0 96yCTkAPeEjeuSljhKeb0IdJW5A98e0qBAWofi2xcN273oo4YhQ2CXAAAOUxK7sZXrin 3WKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=MkzqrGgv; 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 s136-20020a632c8e000000b003dbb2eccf7dsi8859708pgs.614.2022.05.28.02.16.12; Sat, 28 May 2022 02:16:49 -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=MkzqrGgv; 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 S234279AbiE0SeK (ORCPT + 99 others); Fri, 27 May 2022 14:34:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235953AbiE0SeH (ORCPT ); Fri, 27 May 2022 14:34:07 -0400 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6DFBB0A4E for ; Fri, 27 May 2022 11:34:05 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id t20so932904wrh.11 for ; Fri, 27 May 2022 11:34:05 -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=ZMRaR78nxxjwROTv5Xv0uCrlGpUNKsmrgGJVBdvr8Ow=; b=MkzqrGgvYlJnACcMhuImZMacQWLHV1sfIdXNuvsTHnrOm/OtJW/K9hyD3QxlczsLoT y8wk264wphMEIWY/RDJ7JWPjvXefBQcB7eVBOUBhZ+RsMwz/xaX7hq5oPUFVoNm6gk+9 ECC8TXoBKcjMQzd/Lx+VaeiZUjV0ikBmp5ZprAw/qhOBi6WaPZolyclGk7kbaG4wUmNU +mIFZCiGrm+cA09ar5e2i9xVloL7GuFnwLMsoJoJXN3aAZ1DbrqnVYdqcioLJkScP577 ZEsHAj7/WcJolt2zrK/cc8Q5BlFMYbDm2Oga3A+8NHOYgCiMkGz8pf41smTE0Irti5Jf eM3A== 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=ZMRaR78nxxjwROTv5Xv0uCrlGpUNKsmrgGJVBdvr8Ow=; b=TVH8wYO3+NHpfLc0lvzqpo3cIPW26r7cNu1xAfhn9BETIcmoXUD0NjcrfXNTmDeQfE +d+a5QpdRnFSsfX+o4Z+q7KFvk3hqEO/lFsIeoRxdYnYSGHr6rrK/5yYlxrctIWwbH10 Hr6i9j8L7rGcqOopXvfC6iCXIIJmfHV6uVXXd7eFLjwoRbQSVdf4fIHkWN2js583pK3S gJPoPpZvrIZOSFk3GMzojrjZxYurRAaQ9Bx4d034XOVjk1OwCWOKq1WREw0IjFVv1VMR lOhlcrfchf/qQOAdHy5UgpP9+e3l2Jz0EbpjPQ7Jfsjp/wuOVSoIsf0+N4CjK7ccJDj4 y+7Q== X-Gm-Message-State: AOAM530IH08gvMkXgdM0kEsgJA74bCzzo4BQr7n0jGXclk4HKS6yoy83 CwU4nPYkn4bpFukrZ+r1QGU77uMhsszoAL4SjiyCEQ== X-Received: by 2002:a05:6000:544:b0:20f:ca41:cc4c with SMTP id b4-20020a056000054400b0020fca41cc4cmr26548956wrf.582.1653676444165; Fri, 27 May 2022 11:34:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Ahmed Date: Fri, 27 May 2022 11:33:27 -0700 Message-ID: Subject: Re: [PATCH v4 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses. To: Sean Christopherson Cc: Johannes Weiner , Shakeel Butt , 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=unavailable 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 Wed, May 25, 2022 at 5:39 PM Sean Christopherson wrote: > > On Wed, May 25, 2022, Johannes Weiner wrote: > > On Tue, May 24, 2022 at 03:31:52PM -0700, Yosry Ahmed wrote: > > > 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. > > After a lot of waffling, my vote is to add a dedicated NR_SECONDARY_PAGETABLE. > > It's somewhat redundant from a KVM perspective, as NR_SECONDARY_PAGETABLE will > scale with KVM's per-VM pages_{4k,2m,1g} stats unless the guest is doing something > bizarre, e.g. accessing only 4kb chunks of 2mb pages so that KVM is forced to > allocate a large number of page tables even though the guest isn't accessing that > much memory. > > But, someone would need to either understand how KVM works to make that connection, > or know (or be told) to go look at KVM's stats if they're running VMs to better > decipher the stats. > > And even in the little bit of time I played with this, I found having > nr_page_table_pages side-by-side with nr_secondary_page_table_pages to be very > informative. E.g. when backing a VM with THP versus HugeTLB, > nr_secondary_page_table_pages is roughly the same, but nr_page_table_pages is an > order of a magnitude higher with THP. I'm guessing the THP behavior is due to > something triggering DoubleMap, but now I want to find out why that's happening. > > So while I'm pretty sure a clever user could glean the same info by cross-referencing > NR_PAGETABLE stats with KVM stats, I think having NR_SECONDARY_PAGETABLE will at the > very least prove to be helpful for understanding tradeoffs between VM backing types, > and likely even steer folks towards potential optimizations. > > Baseline: > # grep page_table /proc/vmstat > nr_page_table_pages 2830 > nr_secondary_page_table_pages 0 > > THP: > # grep page_table /proc/vmstat > nr_page_table_pages 7584 > nr_secondary_page_table_pages 140 > > HugeTLB: > # grep page_table /proc/vmstat > nr_page_table_pages 3153 > nr_secondary_page_table_pages 153 > Interesting findings! Thanks for taking the time to look into this, Sean! I will refresh this patchset and summarize the discussion in the commit message, and also fix some nits on the KVM side. Does this sound good to everyone?