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. :)
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
