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

Marcelo Tosatti
2014-12-10T17:34:30Z

On Wed, Dec 10, 2014 at 06:08:14PM +0100, Paolo Bonzini wrote:
>
>
> On 10/12/2014 17:53, Marcelo.Tosatti@amt.cnet wrote:
> > For the hrtimer which emulates the tscdeadline timer in the guest,
> > add an option to advance expiration, and busy spin on VM-entry waiting
> > for the actual expiration time to elapse.
> >
> > This allows achieving low latencies in cyclictest (or any scenario
> > which requires strict timing regarding timer expiration).
> >
> > Reduces cyclictest avg latency by 50%.
> >
> > Note: this option requires tuning to find the appropriate value
> > for a particular hardware/guest combination. One method is to measure the
> > average delay between apic_timer_fn and VM-entry.
> > Another method is to start with 1000ns, and increase the value
> > in say 500ns increments until avg cyclictest numbers stop decreasing.
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>
> What is the latency value that you find in practice, for both
> apic_timer_fn to vmentry? Or for apic_timer_fn to just before vmrun?

7us between apic_timer_fn and kvm_entry tracepoint.

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

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

> 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?

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.