* [PATCH] KVM: MMU: increment stats after event occurrence
@ 2012-01-13 1:08 Davidlohr Bueso
2012-01-13 1:24 ` Takuya Yoshikawa
0 siblings, 1 reply; 4+ messages in thread
From: Davidlohr Bueso @ 2012-01-13 1:08 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti, Xiao Guangrong; +Cc: lkml, kvm
From: Davidlohr Bueso <dave@gnu.org>
It makes more sense to actually increment statistics for tlb flushes and page table entry updates after such _events_ occur, instead of before.
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
---
arch/x86/kvm/mmu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2a2a9b4..0b7008e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3130,8 +3130,8 @@ static int nonpaging_init_context(struct kvm_vcpu *vcpu,
void kvm_mmu_flush_tlb(struct kvm_vcpu *vcpu)
{
- ++vcpu->stat.tlb_flush;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
+ ++vcpu->stat.tlb_flush;
}
static void paging_new_cr3(struct kvm_vcpu *vcpu)
@@ -3486,8 +3486,8 @@ static void mmu_pte_write_new_pte(struct kvm_vcpu *vcpu,
return;
}
- ++vcpu->kvm->stat.mmu_pte_updated;
vcpu->arch.mmu.update_pte(vcpu, sp, spte, new);
+ ++vcpu->kvm->stat.mmu_pte_updated;
}
static bool need_remote_flush(u64 old, u64 new)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] KVM: MMU: increment stats after event occurrence
2012-01-13 1:08 [PATCH] KVM: MMU: increment stats after event occurrence Davidlohr Bueso
@ 2012-01-13 1:24 ` Takuya Yoshikawa
2012-01-13 12:56 ` Davidlohr Bueso
0 siblings, 1 reply; 4+ messages in thread
From: Takuya Yoshikawa @ 2012-01-13 1:24 UTC (permalink / raw)
To: dave; +Cc: Avi Kivity, Marcelo Tosatti, Xiao Guangrong, lkml, kvm
(2012/01/13 10:08), Davidlohr Bueso wrote:
> From: Davidlohr Bueso<dave@gnu.org>
>
> It makes more sense to actually increment statistics for tlb flushes and page table entry updates after such _events_ occur, instead of before.
Why?
Takuya
>
> Signed-off-by: Davidlohr Bueso<dave@gnu.org>
> ---
> arch/x86/kvm/mmu.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 2a2a9b4..0b7008e 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -3130,8 +3130,8 @@ static int nonpaging_init_context(struct kvm_vcpu *vcpu,
>
> void kvm_mmu_flush_tlb(struct kvm_vcpu *vcpu)
> {
> - ++vcpu->stat.tlb_flush;
> kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
> + ++vcpu->stat.tlb_flush;
> }
>
> static void paging_new_cr3(struct kvm_vcpu *vcpu)
> @@ -3486,8 +3486,8 @@ static void mmu_pte_write_new_pte(struct kvm_vcpu *vcpu,
> return;
> }
>
> - ++vcpu->kvm->stat.mmu_pte_updated;
> vcpu->arch.mmu.update_pte(vcpu, sp, spte, new);
> + ++vcpu->kvm->stat.mmu_pte_updated;
> }
>
> static bool need_remote_flush(u64 old, u64 new)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] KVM: MMU: increment stats after event occurrence
2012-01-13 1:24 ` Takuya Yoshikawa
@ 2012-01-13 12:56 ` Davidlohr Bueso
2012-01-15 14:04 ` Avi Kivity
0 siblings, 1 reply; 4+ messages in thread
From: Davidlohr Bueso @ 2012-01-13 12:56 UTC (permalink / raw)
To: Takuya Yoshikawa; +Cc: Avi Kivity, Marcelo Tosatti, Xiao Guangrong, lkml, kvm
On Fri, 2012-01-13 at 10:24 +0900, Takuya Yoshikawa wrote:
> (2012/01/13 10:08), Davidlohr Bueso wrote:
> > From: Davidlohr Bueso<dave@gnu.org>
> >
> > It makes more sense to actually increment statistics for tlb flushes and page table entry updates after such _events_ occur, instead of before.
>
> Why?
>
>From a logical point of view its better to increase stats once the event
is processed - usually because it can fail and therefore the stats would
be incorrect.
> Takuya
>
> >
> > Signed-off-by: Davidlohr Bueso<dave@gnu.org>
> > ---
> > arch/x86/kvm/mmu.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index 2a2a9b4..0b7008e 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -3130,8 +3130,8 @@ static int nonpaging_init_context(struct kvm_vcpu *vcpu,
> >
> > void kvm_mmu_flush_tlb(struct kvm_vcpu *vcpu)
> > {
> > - ++vcpu->stat.tlb_flush;
> > kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
> > + ++vcpu->stat.tlb_flush;
> > }
> >
> > static void paging_new_cr3(struct kvm_vcpu *vcpu)
> > @@ -3486,8 +3486,8 @@ static void mmu_pte_write_new_pte(struct kvm_vcpu *vcpu,
> > return;
> > }
> >
> > - ++vcpu->kvm->stat.mmu_pte_updated;
> > vcpu->arch.mmu.update_pte(vcpu, sp, spte, new);
> > + ++vcpu->kvm->stat.mmu_pte_updated;
> > }
> >
> > static bool need_remote_flush(u64 old, u64 new)
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] KVM: MMU: increment stats after event occurrence
2012-01-13 12:56 ` Davidlohr Bueso
@ 2012-01-15 14:04 ` Avi Kivity
0 siblings, 0 replies; 4+ messages in thread
From: Avi Kivity @ 2012-01-15 14:04 UTC (permalink / raw)
To: dave; +Cc: Takuya Yoshikawa, Marcelo Tosatti, Xiao Guangrong, lkml, kvm
On 01/13/2012 02:56 PM, Davidlohr Bueso wrote:
> On Fri, 2012-01-13 at 10:24 +0900, Takuya Yoshikawa wrote:
> > (2012/01/13 10:08), Davidlohr Bueso wrote:
> > > From: Davidlohr Bueso<dave@gnu.org>
> > >
> > > It makes more sense to actually increment statistics for tlb flushes and page table entry updates after such _events_ occur, instead of before.
> >
> > Why?
> >
> From a logical point of view its better to increase stats once the event
> is processed - usually because it can fail and therefore the stats would
> be incorrect.
>
That doesn't hold for the cases you change.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-01-15 14:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-13 1:08 [PATCH] KVM: MMU: increment stats after event occurrence Davidlohr Bueso
2012-01-13 1:24 ` Takuya Yoshikawa
2012-01-13 12:56 ` Davidlohr Bueso
2012-01-15 14:04 ` Avi Kivity
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).