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 X-Spam-Level: X-Spam-Status: No, score=-20.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FABDC4320A for ; Mon, 2 Aug 2021 23:02:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F385460D07 for ; Mon, 2 Aug 2021 23:02:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232424AbhHBXCW (ORCPT ); Mon, 2 Aug 2021 19:02:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231126AbhHBXCU (ORCPT ); Mon, 2 Aug 2021 19:02:20 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0391BC061764 for ; Mon, 2 Aug 2021 16:02:10 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id u9-20020a17090a1f09b029017554809f35so1172200pja.5 for ; Mon, 02 Aug 2021 16:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XV9UPUrTxP4Ixd39NjPRpfiBzgebHxwcML8doCOTbGA=; b=DoSjX0xn1IFHcljzQWXaX4qWghU8BrPIkMskbzgpEDDfl7aSK2Xh6BD7FzofqDf0Fb XXSB5+14WKQGLAEM9cjZw9VcBF7vdJESEy73pN5jlW81JSUpwPkBWte/xpCwy++4STGk raWMwUz3qqV5FXUToHzQ0IC/RN6mDrnGvRiw8MSVRcvT2YrvYrnFpLDTTN7i+Pt6+aQM ObmhMmbx8fAmjjgH1OuXW/LFFJ6cxp3DZO9lT5IPeHg/dne6LbpWIcetzjFYTCc5726J E4Rwq2Yirt+31R0k0bFKUks0Cw5gCQMY7lg1tZ9OiuPPNPJRg/CNVhTzDmlESBjXjFdE SAxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XV9UPUrTxP4Ixd39NjPRpfiBzgebHxwcML8doCOTbGA=; b=X2o8VRdC/mZw/xTjXng8N6NzXaXZxhj+6nOGMFqx2iNoIPLTmiMxvXZ9N0img9N7Z4 upEoO6hLEvM1HjlB75qyetpTfIUli9bgkOIrGnKI4eDXdicIOCOwvi5vmZaSDS/U8zq7 Vuo365cm283zZVXPdjnqtbZOtvWSVGPhThb7nldtOMx9nDHcsLQOryo+c3kN3KWFrdBf 2bWc0wTEmiff0M0YqVa2gv50CYpA5zc3dEVE7vvtLMlA5+6aBkhXtvbfGSO/z7xhH7N2 TMtygsVCYoEHt4lzX9md5bGgGyMmZSliL5iVffXzE03E/Ka8pGbL9aN6S1UTqEhxN5eP XVMg== X-Gm-Message-State: AOAM5319r9ABiPkHtwH1qOmvduhT1mGKqT+FBUzgd/W9Dt8v7jdCHbsP 6evg6uCvncVZb+y00l83fo8RKA== X-Google-Smtp-Source: ABdhPJysL9JBlR9jcnP1/RkK0f8gbfD62Opo7zyGuEqkVHjgKUHoriTfr/2UTgA2HdkQbsaYnZAWPA== X-Received: by 2002:a17:90a:e289:: with SMTP id d9mr19221033pjz.186.1627945329423; Mon, 02 Aug 2021 16:02:09 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id z11sm3481413pfr.201.2021.08.02.16.02.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Aug 2021 16:02:08 -0700 (PDT) Date: Mon, 2 Aug 2021 23:02:05 +0000 From: Sean Christopherson To: Mingwei Zhang Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Gardon , Jing Zhang , David Matlack Subject: Re: [PATCH v3 3/3] KVM: x86/mmu: Add detailed page size stats Message-ID: References: <20210730225939.3852712-1-mizhang@google.com> <20210730225939.3852712-4-mizhang@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210730225939.3852712-4-mizhang@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 30, 2021, Mingwei Zhang wrote: > Existing KVM code tracks the number of large pages regardless of their > sizes. Therefore, when large page of 1GB (or larger) is adopted, the > information becomes less useful because lpages counts a mix of 1G and 2M > pages. > > So remove the lpages since it is easy for user space to aggregate the info. > Instead, provide a comprehensive page stats of all sizes from 4K to 512G. > > Suggested-by: Ben Gardon > Reviewed-by: Ben Gardon > Signed-off-by: Mingwei Zhang > Cc: Jing Zhang > Cc: David Matlack > Cc: Sean Christopherson Looks good, but you'll probably need/want to rebase to kvm/queue once that settles down (I suspect a forced push is coming this week). This has quite a few conflicts with other stuff sitting in kvm/queue. > --- > arch/x86/include/asm/kvm_host.h | 10 +++++++++- > arch/x86/kvm/mmu.h | 4 ++++ > arch/x86/kvm/mmu/mmu.c | 26 +++++++++++++------------- > arch/x86/kvm/mmu/tdp_mmu.c | 15 ++------------- > arch/x86/kvm/x86.c | 7 +++++-- > 5 files changed, 33 insertions(+), 29 deletions(-) > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index 974cbfb1eefe..eb6edc36b3ed 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -1206,9 +1206,17 @@ struct kvm_vm_stat { > u64 mmu_recycled; > u64 mmu_cache_miss; > u64 mmu_unsync; > - u64 lpages; > u64 nx_lpage_splits; > u64 max_mmu_page_hash_collisions; > + union { > + struct { > + atomic64_t pages_4k; > + atomic64_t pages_2m; > + atomic64_t pages_1g; > + atomic64_t pages_512g; > + }; > + atomic64_t pages[4]; > + }; ... > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 8166ad113fb2..e4dfcd5d83ad 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -235,9 +235,12 @@ const struct _kvm_stats_desc kvm_vm_stats_desc[] = { > STATS_DESC_COUNTER(VM, mmu_recycled), > STATS_DESC_COUNTER(VM, mmu_cache_miss), > STATS_DESC_ICOUNTER(VM, mmu_unsync), > - STATS_DESC_ICOUNTER(VM, lpages), > STATS_DESC_ICOUNTER(VM, nx_lpage_splits), > - STATS_DESC_PCOUNTER(VM, max_mmu_page_hash_collisions) > + STATS_DESC_PCOUNTER(VM, max_mmu_page_hash_collisions), > + STATS_DESC_ICOUNTER(VM, pages_4k), > + STATS_DESC_ICOUNTER(VM, pages_2m), > + STATS_DESC_ICOUNTER(VM, pages_1g), > + STATS_DESC_ICOUNTER(VM, pages_512g) Uber nit that I wouldn't even have noticed if this didn't conflict, but there's no need to land the union and the stats definitions at the end of the structs, i.e. the new fields can directly replace lpages. I don't think it will actually avoid a conflict, but it would avoid modifying the max_mmu_page_hash_collisions line. > }; > static_assert(ARRAY_SIZE(kvm_vm_stats_desc) == > sizeof(struct kvm_vm_stat) / sizeof(u64)); > -- > 2.32.0.554.ge1b32706d8-goog >