diff mbox series

KVM: stats: Add VM stat for remote tlb flush requests

Message ID 20210817002639.3856694-1-jingzhangos@google.com (mailing list archive)
State New, archived
Headers show
Series KVM: stats: Add VM stat for remote tlb flush requests | expand

Commit Message

Jing Zhang Aug. 17, 2021, 12:26 a.m. UTC
Add a new stat that counts the number of times a remote TLB flush is
requested, regardless of whether it kicks vCPUs out of guest mode. This
allows us to look at how often flushes are initiated.

Original-by: David Matlack <dmatlack@google.com>
Signed-off-by: Jing Zhang <jingzhangos@google.com>
---
 arch/arm64/kvm/mmu.c      | 1 +
 include/linux/kvm_host.h  | 3 ++-
 include/linux/kvm_types.h | 1 +
 virt/kvm/kvm_main.c       | 1 +
 4 files changed, 5 insertions(+), 1 deletion(-)


base-commit: a3e0b8bd99ab098514bde2434301fa6fde040da2

Comments

Marc Zyngier Aug. 18, 2021, 8:11 a.m. UTC | #1
On Tue, 17 Aug 2021 01:26:39 +0100,
Jing Zhang <jingzhangos@google.com> wrote:
> 
> Add a new stat that counts the number of times a remote TLB flush is
> requested, regardless of whether it kicks vCPUs out of guest mode. This
> allows us to look at how often flushes are initiated.

nit: this is a very x86-centric view of things. On arm64, TLB
invalidation is broadcast in HW, and does not interrupt the guest
execution.

> 
> Original-by: David Matlack <dmatlack@google.com>
> Signed-off-by: Jing Zhang <jingzhangos@google.com>
> ---
>  arch/arm64/kvm/mmu.c      | 1 +
>  include/linux/kvm_host.h  | 3 ++-
>  include/linux/kvm_types.h | 1 +
>  virt/kvm/kvm_main.c       | 1 +
>  4 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 0625bf2353c2..f5bb235bbb59 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -80,6 +80,7 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot)
>   */
>  void kvm_flush_remote_tlbs(struct kvm *kvm)
>  {
> +	++kvm->stat.generic.remote_tlb_flush_requests;
>  	kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu);
>  }

We already have this queued for 5.15 [1].

Thanks,

	M.

[1] https://lore.kernel.org/r/20210727103251.16561-1-pbonzini@redhat.com
Jing Zhang Aug. 18, 2021, 4:15 p.m. UTC | #2
Hi Marc,

On Wed, Aug 18, 2021 at 1:11 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Tue, 17 Aug 2021 01:26:39 +0100,
> Jing Zhang <jingzhangos@google.com> wrote:
> >
> > Add a new stat that counts the number of times a remote TLB flush is
> > requested, regardless of whether it kicks vCPUs out of guest mode. This
> > allows us to look at how often flushes are initiated.
>
> nit: this is a very x86-centric view of things. On arm64, TLB
> invalidation is broadcast in HW, and does not interrupt the guest
> execution.
>
Understood. Thanks.
> >
> > Original-by: David Matlack <dmatlack@google.com>
> > Signed-off-by: Jing Zhang <jingzhangos@google.com>
> > ---
> >  arch/arm64/kvm/mmu.c      | 1 +
> >  include/linux/kvm_host.h  | 3 ++-
> >  include/linux/kvm_types.h | 1 +
> >  virt/kvm/kvm_main.c       | 1 +
> >  4 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 0625bf2353c2..f5bb235bbb59 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -80,6 +80,7 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> >   */
> >  void kvm_flush_remote_tlbs(struct kvm *kvm)
> >  {
> > +     ++kvm->stat.generic.remote_tlb_flush_requests;
> >       kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu);
> >  }
>
> We already have this queued for 5.15 [1].
I guess you mean the change for "remote_tlb_flush" has been queued,
not "remote_tlb_flush_requests"?
These two counters would have the same value for arm64, but not for
others (at least x86).
>
> Thanks,
>
>         M.
>
> [1] https://lore.kernel.org/r/20210727103251.16561-1-pbonzini@redhat.com
>
> --
> Without deviation from the norm, progress is not possible.

Thanks,
Jing
Marc Zyngier Aug. 18, 2021, 4:52 p.m. UTC | #3
On Wed, 18 Aug 2021 17:15:36 +0100,
Jing Zhang <jingzhangos@google.com> wrote:
> 
> Hi Marc,
> 
> On Wed, Aug 18, 2021 at 1:11 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Tue, 17 Aug 2021 01:26:39 +0100,
> > Jing Zhang <jingzhangos@google.com> wrote:
> > >
> > > Add a new stat that counts the number of times a remote TLB flush is
> > > requested, regardless of whether it kicks vCPUs out of guest mode. This
> > > allows us to look at how often flushes are initiated.
> >
> > nit: this is a very x86-centric view of things. On arm64, TLB
> > invalidation is broadcast in HW, and does not interrupt the guest
> > execution.
> >
> Understood. Thanks.
> > >
> > > Original-by: David Matlack <dmatlack@google.com>
> > > Signed-off-by: Jing Zhang <jingzhangos@google.com>
> > > ---
> > >  arch/arm64/kvm/mmu.c      | 1 +
> > >  include/linux/kvm_host.h  | 3 ++-
> > >  include/linux/kvm_types.h | 1 +
> > >  virt/kvm/kvm_main.c       | 1 +
> > >  4 files changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index 0625bf2353c2..f5bb235bbb59 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > > @@ -80,6 +80,7 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> > >   */
> > >  void kvm_flush_remote_tlbs(struct kvm *kvm)
> > >  {
> > > +     ++kvm->stat.generic.remote_tlb_flush_requests;
> > >       kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu);
> > >  }
> >
> > We already have this queued for 5.15 [1].
> I guess you mean the change for "remote_tlb_flush" has been queued,
> not "remote_tlb_flush_requests"?

Yes, this is what I meant, as I only quoted the bit that was redundant.

> These two counters would have the same value for arm64, but not for
> others (at least x86).

Sure. It is just that this patch does two things at once, but doesn't
advertise it.

Thanks,

	M.
Paolo Bonzini Sept. 6, 2021, 10:30 a.m. UTC | #4
On 18/08/21 18:52, Marc Zyngier wrote:
> Yes, this is what I meant, as I only quoted the bit that was redundant.
> 
>> These two counters would have the same value for arm64, but not for
>> others (at least x86).
> Sure. It is just that this patch does two things at once, but doesn't
> advertise it.

All in all, Jing's new stat is more appropriate than the one I used. 
I'll fix the conflict when pulling from you.

Paolo
diff mbox series

Patch

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 0625bf2353c2..f5bb235bbb59 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -80,6 +80,7 @@  static bool memslot_is_logging(struct kvm_memory_slot *memslot)
  */
 void kvm_flush_remote_tlbs(struct kvm *kvm)
 {
+	++kvm->stat.generic.remote_tlb_flush_requests;
 	kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu);
 }
 
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d447b21cdd73..27cb69e564cb 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1444,7 +1444,8 @@  struct _kvm_stats_desc {
 		KVM_STATS_BASE_POW10, -9, sz)
 
 #define KVM_GENERIC_VM_STATS()						       \
-	STATS_DESC_COUNTER(VM_GENERIC, remote_tlb_flush)
+	STATS_DESC_COUNTER(VM_GENERIC, remote_tlb_flush),		       \
+	STATS_DESC_COUNTER(VM_GENERIC, remote_tlb_flush_requests)
 
 #define KVM_GENERIC_VCPU_STATS()					       \
 	STATS_DESC_COUNTER(VCPU_GENERIC, halt_successful_poll),		       \
diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
index de7fb5f364d8..2237abb93ccd 100644
--- a/include/linux/kvm_types.h
+++ b/include/linux/kvm_types.h
@@ -80,6 +80,7 @@  struct kvm_mmu_memory_cache {
 
 struct kvm_vm_stat_generic {
 	u64 remote_tlb_flush;
+	u64 remote_tlb_flush_requests;
 };
 
 struct kvm_vcpu_stat_generic {
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3e67c93ca403..26b77ab98a04 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -318,6 +318,7 @@  void kvm_flush_remote_tlbs(struct kvm *kvm)
 	 */
 	long dirty_count = smp_load_acquire(&kvm->tlbs_dirty);
 
+	++kvm->stat.generic.remote_tlb_flush_requests;
 	/*
 	 * We want to publish modifications to the page tables before reading
 	 * mode. Pairs with a memory barrier in arch-specific code.