From patchwork Tue Oct 25 11:43:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= X-Patchwork-Id: 9394373 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4A2AE6077F for ; Tue, 25 Oct 2016 11:43:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3B81829536 for ; Tue, 25 Oct 2016 11:43:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2FB5029539; Tue, 25 Oct 2016 11:43:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D555D29536 for ; Tue, 25 Oct 2016 11:43:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934133AbcJYLnk (ORCPT ); Tue, 25 Oct 2016 07:43:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60484 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933548AbcJYLnj (ORCPT ); Tue, 25 Oct 2016 07:43:39 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2F043B720; Tue, 25 Oct 2016 11:43:38 +0000 (UTC) Received: from potion (dhcp-1-100.brq.redhat.com [10.34.1.100]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id u9PBhZSa017956; Tue, 25 Oct 2016 07:43:36 -0400 Received: by potion (sSMTP sendmail emulation); Tue, 25 Oct 2016 13:43:35 +0200 Date: Tue, 25 Oct 2016 13:43:35 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Wanpeng Li Cc: Paolo Bonzini , "linux-kernel@vger.kernel.org" , kvm , Yunhong Jiang , Wanpeng Li Subject: Re: [PATCH 6/5] KVM: x86: fix periodic lapic timer with hrtimers Message-ID: <20161025114334.GD3197@potion> References: <1477304593-3453-1-git-send-email-wanpeng.li@hotmail.com> <20161024150323.GB2247@potion> <20161024152737.GB3197@potion> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 25 Oct 2016 11:43:38 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 2016-10-25 07:39+0800, Wanpeng Li: > 2016-10-24 23:27 GMT+08:00 Radim Krčmář : >> 2016-10-24 17:09+0200, Paolo Bonzini: >>> On 24/10/2016 17:03, Radim Krčmář wrote: >> [...] >>> >>> Reviewed-by: Paolo Bonzini >>> >>> 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. 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. --- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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; }