All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm <kvm@vger.kernel.org>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Wanpeng Li <wanpeng.li@hotmail.com>
Subject: Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers
Date: Tue, 25 Oct 2016 13:43:35 +0200	[thread overview]
Message-ID: <20161025114334.GD3197@potion> (raw)
In-Reply-To: <CANRm+CypjCjAJPzbd7SfHVB0940sMQx7Zz_0dbn=Dg-AkHNd9A@mail.gmail.com>

2016-10-25 07:39+0800, Wanpeng Li:
> 2016-10-24 23:27 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
>> 2016-10-24 17:09+0200, Paolo Bonzini:
>>> On 24/10/2016 17:03, Radim Krčmář wrote:
>> [...]
>>>
>>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>>>
>>> Go ahead, squash it into 5/5 and commit to kvm/queue. :)
>>
>> Did that, thanks.
>>
>> Wanpeng, the code is now under your name so please check it and/or
>> complain.
> 
> This patch 6/5 incurred regressions.
> 
> - The latency of the periodic mode which is emulated by VMX preemption
> is almost the same as periodic mode which is emulated by hrtimer.

Hm, what numbers are you getting?

When I ran the test with the original series, then it actually had worse
results with the VMX preemption than it did with the hrimer:

  hlt average latency   = 1464151
  pause average latency = 1467605

htl tests the hrtimer, pause tests the VMX preemption.  I just replaced
"hlt" with "pause" in the assembly loop.

The worse result was because the VMX preemption period was computed
incorrectly -- it was being added to now().  Some time passes between
the expiration and reading of now(), so this time was extending the
period while it shouldn't have.

If I run the test with [6/5], it gets sane numbers:

  hlt average latency   = 1465107
  pause average latency = 1465093

The numbers are sane bacause the test is not computing latency (= how
long after the timer should have fired have we received the interrupt)
-- it is computing the duration of the period in cycles, which is much
better right now.

> - The oneshot mode test of kvm-unit-tests/apic_timer_latency.flat almost fail.

Oops, silly mistake -- apic_timer_expired() was in the 'else' branch in
[5/5] and I didn't invert the condition after moving it.

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 6244988418be..d7e74c8ec8ca 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1354,8 +1354,8 @@ static void start_sw_period(struct kvm_lapic *apic)
 		return;
 
 	if (apic_lvtt_oneshot(apic) &&
-	    ktime_after(apic->lapic_timer.target_expiration,
-	                apic->lapic_timer.timer.base->get_time())) {
+	    !ktime_after(apic->lapic_timer.target_expiration,
+	                 apic->lapic_timer.timer.base->get_time())) {
 		apic_timer_expired(apic);
 		return;
 	}

Paolo, can you squash that?

> Btw, hope you can also apply the testcase for kvm-unit-tests. :)

I will have some comments, because it would be nicer if it measured the
latency ... expected_expiration is not computed correctly.

  reply	other threads:[~2016-10-25 11:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 10:23 [PATCH v3 0/5] KVM: LAPIC: Add APIC Timer periodic/oneshot mode VMX preemption timer support Wanpeng Li
2016-10-24 10:23 ` [PATCH v3 1/5] KVM: LAPIC: extract start_sw_period() to handle periodic/oneshot mode Wanpeng Li
2016-10-24 10:23 ` [PATCH v3 2/5] KVM: LAPIC: guarantee the timer is in tsc-deadline mode Wanpeng Li
2016-10-24 10:23 ` [PATCH v3 3/5] KVM: LAPIC: introduce kvm_get_lapic_target_expiration_tsc() Wanpeng Li
2016-10-24 10:23 ` [PATCH v3 4/5] KVM: LAPIC: rename start/cancel_hv_tscdeadline to start/cancel_hv_timer Wanpeng Li
2016-10-24 10:23 ` [PATCH v3 5/5] KVM: LAPIC: add APIC Timer periodic/oneshot mode VMX preemption timer support Wanpeng Li
2016-10-24 14:50   ` Radim Krčmář
2016-10-24 23:33     ` Wanpeng Li
2016-10-24 15:03 ` [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers Radim Krčmář
2016-10-24 15:09   ` Paolo Bonzini
2016-10-24 15:27     ` Radim Krčmář
2016-10-24 23:39       ` Wanpeng Li
2016-10-25 11:43         ` Radim Krčmář [this message]
2016-10-25 11:55           ` Paolo Bonzini
2016-10-26  6:02           ` Wanpeng Li
2016-10-26  6:08             ` Wanpeng Li
2016-10-26 14:01               ` Radim Krčmář
2016-10-27  2:33                 ` Wanpeng Li
2016-10-26 13:32             ` Radim Krčmář
2016-10-27  2:11               ` Wanpeng Li
2016-10-26 10:23           ` Wanpeng Li
2016-10-26 11:15             ` Paolo Bonzini
2016-10-26 11:26               ` Wanpeng Li
     [not found]   ` <SG2PR02MB1550E0FF04F2614BE0E262BC80A80@SG2PR02MB1550.apcprd02.prod.outlook.com>
2016-10-25 13:03     ` Radim Krčmář

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=20161025114334.GD3197@potion \
    --to=rkrcmar@redhat.com \
    --cc=kernellwp@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=wanpeng.li@hotmail.com \
    --cc=yunhong.jiang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.