From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [patch 2/3] KVM: x86: add option to advance tscdeadline hrtimer expiration Date: Wed, 17 Dec 2014 18:48:26 +0100 Message-ID: <5491C1EA.7040706@redhat.com> References: <20141216140813.493421022@redhat.com> <20141216140853.687723255@redhat.com> <20141217145805.GA29368@potion.brq.redhat.com> <20141217174139.GA31721@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Luiz Capitulino , Rik van Riel To: Marcelo Tosatti , Radim Krcmar Return-path: Received: from mail-wg0-f52.google.com ([74.125.82.52]:41835 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750790AbaLQRsb (ORCPT ); Wed, 17 Dec 2014 12:48:31 -0500 Received: by mail-wg0-f52.google.com with SMTP id x12so20876887wgg.25 for ; Wed, 17 Dec 2014 09:48:30 -0800 (PST) In-Reply-To: <20141217174139.GA31721@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 17/12/2014 18:41, Marcelo Tosatti wrote: >> > Btw. simple automatic delta tuning had worse results? > Haven't tried automatic tuning. > > So what happens on a realtime environment is this: you execute the fixed > number of instructions from interrupt handling all the way to VM-entry. > > Well, almost fixed. Fixed is the number of apic_timer_fn plus KVM > instructions. You can also execute host scheduler and timekeeping > processing. > > In practice, the length to execute that instruction sequence is a bell > shaped normal distribution around the average (the right side is > slightly higher due to host scheduler and timekeeping processing). > > You want to advance the timer by the rightmost bucket, that way you > guarantee lower possible latencies (which is the interest here). > > That said, i don't see advantage in automatic tuning for the usecase > which this targets. Yeah, the value of the parameter can be computed pretty easily from either the tracepoint or the kvm-unit-tests testcase. Paolo