From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [patch 2/2] KVM: x86: add option to advance tscdeadline hrtimer expiration Date: Wed, 10 Dec 2014 18:53:48 +0100 Message-ID: <548888AC.8010305@redhat.com> References: <20141210165339.875103463@localhost.localdomain> <20141210165432.367137017@localhost.localdomain> <54887DFE.3070904@redhat.com> <20141210173411.GA21295@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: kvm@vger.kernel.org, Luiz Capitulino , Rik van Riel , Radim Krcmar To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58553 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932268AbaLJRxz (ORCPT ); Wed, 10 Dec 2014 12:53:55 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBAHrrO6021926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 10 Dec 2014 12:53:54 -0500 In-Reply-To: <20141210173411.GA21295@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 10/12/2014 18:34, Marcelo Tosatti wrote: >> > Let's start with a kvm-unit-tests patch to measure this value. > I can, but kvm-unit-test register state will not be similar to > actual guest state (think host/guest state loading). 7us is about 20000 clock cycles. A lightweight vmexit is an order of magnitude less expensive, and half of the vmexit overhead is the VMRUN instruction itself. All in all, the host/guest state loading should not matter (or should matter little). > What is the advantage of using a kvm-unit-test test rather > than cyclictest in the guest ? That it starts in <3 seconds, and that you can vary the timer frequency in order to measure jitter in addition to latency. >> We can then decide whether to hardcode a small default value (e.g. >> 1000-3000) and make it a module parameter? Or perhaps start with a >> higher value (twice what you find in practice?) and adjust it towards a >> target every time wait_lapic_expire is called. But in order to judge >> the correct approach, I need to see the numbers. > > Problem with automatic adjustment is: what is the correct target? We cannot say without seeing the numbers, particularly the jitter. This is why I want to see numbers for varying frequencies (from 100us to 10ms per tick, say). > You want faster instances of apic_timer_fn->vm-entry to spin a bit, > and allow slow instances of apic_timer_fn->vm-entry to have > an effective advancement. If it is small enogh, you can make the timer a little "early" (increase advance) by a small amount on every delivered interrupt. This prepares for a slow instance. And you can make the timer less "early" (decrease advance) by some percentage of what you had to wait on every wait_lapic_expire, if you had to wait more than a given threshold. This avoids that you wait too much on consecutive fast instances. Paolo