Re: [patch 2/2] KVM: x86: add option to advance tscdeadline hrtimer expiration

[Paolo Bonzini <pbonzini@redhat.com>]

On 10/12/2014 18:34, Marcelo Tosatti wrote:
>> > Let's start with a kvm-unit-tests patch to measure this value.
> I can, but kvm-unit-test register state will not be similar to
> actual guest state (think host/guest state loading).

7us is about 20000 clock cycles.  A lightweight vmexit is an order of
magnitude less expensive, and half of the vmexit overhead is the VMRUN
instruction itself.  All in all, the host/guest state loading should not
matter (or should matter little).

> What is the advantage of using a kvm-unit-test test rather
> than cyclictest in the guest ?

That it starts in <3 seconds, and that you can vary the timer frequency
in order to measure jitter in addition to latency.

>> We can then decide whether to hardcode a small default value (e.g.
>> 1000-3000) and make it a module parameter?  Or perhaps start with a
>> higher value (twice what you find in practice?) and adjust it towards a
>> target every time wait_lapic_expire is called.  But in order to judge
>> the correct approach, I need to see the numbers.
> 
> Problem with automatic adjustment is: what is the correct target?

We cannot say without seeing the numbers, particularly the jitter.  This
is why I want to see numbers for varying frequencies (from 100us to 10ms
per tick, say).

> You want faster instances of apic_timer_fn->vm-entry to spin a bit,
> and allow slow instances of apic_timer_fn->vm-entry to have
> an effective advancement.

If it is small enogh, you can make the timer a little "early" (increase
advance) by a small amount on every delivered interrupt.  This prepares
for a slow instance.

And you can make the timer less "early" (decrease advance) by some
percentage of what you had to wait on every wait_lapic_expire, if you
had to wait more than a given threshold.  This avoids that you wait too
much on consecutive fast instances.

Paolo