linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Mingwei Zhang <mizhang@google.com>
Cc: Jim Mattson <jmattson@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Joerg Roedel <joro@8bytes.org>, kvm <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ben Gardon <bgardon@google.com>,
	David Matlack <dmatlack@google.com>,
	Jing Zhang <jingzhangos@google.com>
Subject: Re: [PATCH v4 3/3] KVM: x86/mmu: Add detailed page size stats
Date: Tue, 10 Aug 2021 19:22:37 -0400	[thread overview]
Message-ID: <YRMKPd2ZarXCX6vm@t490s> (raw)
In-Reply-To: <CAL715WLO9+CpNa4ZQX4J2OdyqOBsX0+g0M4bNe+A+6FVxB2OxA@mail.gmail.com>

On Mon, Aug 09, 2021 at 05:01:39PM -0700, Mingwei Zhang wrote:
> Hi Paolo,

Hi, Mingwei,

> 
> I recently looked at the patches queued and I find this patch from
> Peter Xu (Cced), which is also adding 'page stats' information into
> KVM:
> 
> https://patchwork.kernel.org/project/kvm/patch/20210625153214.43106-7-peterx@redhat.com/
> 
> From a functionality point of view, the above patch seems duplicate
> with mine.

The rmap statistics are majorly for rmap, not huge pages.

> But in detail, Peter's approach is using debugfs with
> proper locking to traverse the whole rmap to get the detailed page
> sizes in different granularity.
> 
> In comparison, mine is to add extra code in low level SPTE update
> routines and store aggregated data in kvm->kvm_stats. This data could
> be retrieved from Jing's fd based API without any lock required, but
> it does not provide the fine granular information such as the number
> of contiguous 4KG/2MB/1GB pages.
> 
> So would you mind giving me some feedback on this patch? I would
> really appreciate it.

I have a question: why change to using atomic ops?  As most kvm statistics
seems to be not with atomics before.

AFAIK atomics are expensive, and they get even more expensive when the host is
bigger (it should easily go into ten-nanosecond level).  So I have no idea
whether it's worth it for persuing that accuracy.

Thanks,

-- 
Peter Xu


  reply	other threads:[~2021-08-10 23:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03  4:46 [PATCH v4 0/3] Add detailed page size stats in KVM stats Mingwei Zhang
2021-08-03  4:46 ` [PATCH v4 1/3] KVM: x86/mmu: Remove redundant spte present check in mmu_set_spte Mingwei Zhang
2021-08-03  4:46 ` [PATCH v4 2/3] KVM: x86/mmu: Avoid collision with !PRESENT SPTEs in TDP MMU lpage stats Mingwei Zhang
2021-08-03  4:46 ` [PATCH v4 3/3] KVM: x86/mmu: Add detailed page size stats Mingwei Zhang
2021-08-09 22:26   ` Jim Mattson
2021-08-09 23:39     ` Mingwei Zhang
2021-08-10  0:01       ` Mingwei Zhang
2021-08-10 23:22         ` Peter Xu [this message]
2021-08-11  1:06           ` Mingwei Zhang
2021-08-11 13:12             ` Peter Xu
2021-08-12 17:44               ` Mingwei Zhang
2021-08-11 11:36   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRMKPd2ZarXCX6vm@t490s \
    --to=peterx@redhat.com \
    --cc=bgardon@google.com \
    --cc=dmatlack@google.com \
    --cc=jingzhangos@google.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).