From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757640AbcJZOBT (ORCPT ); Wed, 26 Oct 2016 10:01:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39964 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754006AbcJZOBO (ORCPT ); Wed, 26 Oct 2016 10:01:14 -0400 Date: Wed, 26 Oct 2016 16:01:09 +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: <20161026140109.GB3452@potion> References: <1477304593-3453-1-git-send-email-wanpeng.li@hotmail.com> <20161024150323.GB2247@potion> <20161024152737.GB3197@potion> <20161025114334.GD3197@potion> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 26 Oct 2016 14:01:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016-10-26 14:08+0800, Wanpeng Li: > 2016-10-26 14:02 GMT+08:00 Wanpeng Li : >> 2016-10-25 19:43 GMT+08:00 Radim Krčmář : >>> I will have some comments, because it would be nicer if it measured the >>> latency ... expected_expiration is not computed correctly. >> >> It measured the latency from guest programs the clock event device to >> interrupt injected to guest after timer fire. No. It never computed the time when the timer fires, the test measured the duration of the period. Imagine that the dashed line below is a timeline. Pipe is idealized firing of the periodic timer and caret is the time when the guest read time in the interrupt. The number below caret is the latency. The period is 7. -------------------------------------------- | | | | | | | ^ ^ ^ ^ ^ ^ ^ 1 2 3 1 2 1 1 The test would report "latencies" as: 1 1 1 -2 1 -1 0 because it used now() + period to compute the next expected expiration Similarly in this case, -------------------------------------------- | | | | | | | ^ ^ ^ ^ ^ ^ 6 6 6 6 6 6 The latency is always 6, but the test would report 6 0 0 0 0 0 And if we improved the latency by 1, you'd only see the difference in the first number. The test measured the duration of the period. > When compare this with clock event device which is emulated by > hrtimer, we can calculate the latency bonus from VMX preemption. If we know when the timer should have fired, then we can measure the latency: latency = now() - expected_expiration The hard part is computing expected_expiration() -- it *cannot* be precise with one-shot or periodic APIC timer, because we don't send expected_expiration to KVM, but only a delta and KVM sets expected_expiration based on the delta and some random time when it gets to set the expected_expiration. The guest could do before = now() set_apic_timer(delta) after = now() to get some bounds on the expected expiration -- it would be between "before + delta" and "after + delta".