From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 2/3] KVM: x86: add option to advance tscdeadline hrtimer expiration Date: Thu, 8 Jan 2015 15:41:35 -0200 Message-ID: <20150108174135.GA19806@amt.cnet> References: <20141223205841.410988818@redhat.com> <20141223210046.824105975@redhat.com> <20150105181235.GA5462@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, Luiz Capitulino , Rik van Riel , Paolo Bonzini To: Radim Krcmar , Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34488 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754855AbbAHRlu (ORCPT ); Thu, 8 Jan 2015 12:41:50 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t08HfnqV017575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 8 Jan 2015 12:41:49 -0500 Content-Disposition: inline In-Reply-To: <20150105181235.GA5462@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jan 05, 2015 at 07:12:36PM +0100, Radim Krcmar wrote: > 2014-12-23 15:58-0500, Marcelo Tosatti: > > For the hrtimer which emulates the tscdeadline timer in the guest, > > add an option to advance expiration, and busy spin on VM-entry wait= ing > > for the actual expiration time to elapse. > >=20 > > This allows achieving low latencies in cyclictest (or any scenario=20 > > which requires strict timing regarding timer expiration). > >=20 > > Reduces average cyclictest latency from 12us to 8us > > on Core i5 desktop. > >=20 > > Note: this option requires tuning to find the appropriate value=20 > > for a particular hardware/guest combination. One method is to measu= re the=20 > > average delay between apic_timer_fn and VM-entry.=20 > > Another method is to start with 1000ns, and increase the value > > in say 500ns increments until avg cyclictest numbers stop decreasin= g. > >=20 > > Signed-off-by: Marcelo Tosatti >=20 > Reviewed-by: Radim Kr=C4=8Dm=C3=A1=C5=99 >=20 > (Other patches weren't touched, so my previous Reviewed-by holds.) >=20 > > +++ kvm/arch/x86/kvm/x86.c > > @@ -108,6 +108,10 @@ EXPORT_SYMBOL_GPL(kvm_max_guest_tsc_khz) > > static u32 tsc_tolerance_ppm =3D 250; > > module_param(tsc_tolerance_ppm, uint, S_IRUGO | S_IWUSR); > > =20 > > +/* lapic timer advance (tscdeadline mode only) in nanoseconds */ > > +unsigned int lapic_timer_advance_ns =3D 0; > > +module_param(lapic_timer_advance_ns, uint, S_IRUGO | S_IWUSR); > > + > > static bool backwards_tsc_observed =3D false; > > =20 > > #define KVM_NR_SHARED_MSRS 16 > > @@ -5625,6 +5629,10 @@ static void kvm_timer_init(void) > > __register_hotcpu_notifier(&kvmclock_cpu_notifier_block); > > cpu_notifier_register_done(); > > =20 > > + if (check_tsc_unstable() && lapic_timer_advance_ns) { > > + pr_info("kvm: unstable TSC, disabling lapic_timer_advance_ns\n")= ; > > + lapic_timer_advance_ns =3D 0; >=20 > Does unstable TSC invalidate this feature? > (lapic_timer_advance_ns can be overridden, so we don't differentiate > workflows that calibrate after starting with 0.) Hum, i don't see why. Paolo? > And cover letter is a bit misleading: The condition does nothing to > guarantee TSC based __delay() loop. (Right now, __delay() =3D delay_= tsc() > whenever the hardware has TSC, regardless of stability, thus always.) OK.