From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [RFC PATCH V2 4/4] Utilize the vmx preemption timer for tsc deadline timer Date: Wed, 25 May 2016 16:31:19 +0200 Message-ID: <20160525143119.GD14795@potion> References: <1464128852-14138-1-git-send-email-yunhong.jiang@linux.intel.com> <1464128852-14138-5-git-send-email-yunhong.jiang@linux.intel.com> <20160525132755.GA14795@potion> <08533932-adea-2b86-fba3-db47b1b866c3@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Yunhong Jiang , kvm@vger.kernel.org, mtosatti@redhat.com, kernellwp@gmail.com To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53081 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751518AbcEYObX (ORCPT ); Wed, 25 May 2016 10:31:23 -0400 Content-Disposition: inline In-Reply-To: <08533932-adea-2b86-fba3-db47b1b866c3@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2016-05-25 15:51+0200, Paolo Bonzini: > On 25/05/2016 15:27, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c >> > @@ -1343,6 +1343,85 @@ static void start_sw_tscdeadline(struct kvm= _lapic *apic) >> > +void kvm_lapic_arm_hv_timer(struct kvm_vcpu *vcpu) >> > +{ >>=20 >> Preemption timer needs to be adjusted on every vmentry while hrtimer= is >> set only once. After how many vmentries does preemption timer surpa= ss >> the overhead of hrtimer? >=20 > See my review. :) I hope to get the per-vmentry cost of the preempti= on > timer down to a dozen instructions. I secretly wished to learn what the overhead of hrtimer is. :) Seems like we need a vmexit kvm-unit-test that enables tsc deadline timer while benchmarking. >> > + if (tscdeadline >=3D guest_tsc) >> > + kvm_x86_ops->set_hv_timer(vcpu, tscdeadline - guest_tsc); >> > + else >> > + kvm_x86_ops->set_hv_timer(vcpu, 0); >>=20 >> Calling kvm_lapic_expired_hv_timer will avoid the useless immediate >> vmexit after a vmentry. >=20 > Even if this is common enough to warrant optimizing for it (which I'm > not sure about, and surely depends on the workload), I think it shoul= d > be done later. You'd get the same "useless vmentry" even with > hrtimer-based LAPIC timer. Makes sense. And early return gets harder to do if we move the setup closer to vmlaunch. > You'd get the same "useless vmentry" even with > hrtimer-based LAPIC timer. (hrtimers won't do an entry/exit cycle if they are injected sufficientl= y early. Maybe preemption or userspace exits would make the difference noticeable, but it should be minor too.)