On Wed, 25 May 2016 16:31:19 +0200
Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote:
> 2016-05-25 15:51+0200, Paolo Bonzini:
> > On 25/05/2016 15:27, Radim Krčmář 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) +{
> >>
> >> Preemption timer needs to be adjusted on every vmentry while
> >> hrtimer is set only once. After how many vmentries does
> >> preemption timer surpass the overhead of hrtimer?
> >
> > See my review. :) I hope to get the per-vmentry cost of the
> > preemption timer down to a dozen instructions.
>
> I secretly wished to learn what the overhead of hrtimer is. :)
I think the cost includes "hrtimer cost + timer interrupt ISR +
vm-exit/entry". The hrtimer_start/hrtimer_cancel depends on the current
hrtimer situation. The timer interrupt ISR has far more cost than
VMExit handling. In system w/o PI, a pair of vm-exit/entry can be
caused by the host timer interrupt.
The intial intention of the patch is to reduce the latency, so we
didn't check the overhead of hrtimer with the cost of vmentries. and
that's the reason of a kernel parameter to turn on/off it. I'd still
keep that parameter even with Paolo's new suggestio, although it can be
ON by default now.
BTW, if the VMX preemption timer uses the host tsc, instead of delta
tsc, as parameter, there would be no extra cost at all :(
Thanks
--jyh
>
> Seems like we need a vmexit kvm-unit-test that enables tsc deadline
> timer while benchmarking.
>
> >> > + if (tscdeadline >= guest_tsc)
> >> > + kvm_x86_ops->set_hv_timer(vcpu, tscdeadline -
> >> > guest_tsc);
> >> > + else
> >> > + kvm_x86_ops->set_hv_timer(vcpu, 0);
> >>
> >> Calling kvm_lapic_expired_hv_timer will avoid the useless immediate
> >> vmexit after a vmentry.
> >
> > 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
> > should 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
> sufficiently early. Maybe preemption or userspace exits would make
> the difference noticeable, but it should be minor too.)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
