On Wed, Dec 10, 2014 at 06:08:14PM +0100, Paolo Bonzini wrote: > > > On 10/12/2014 17:53, Marcelo.Tosatti@xxxxxxxx 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@xxxxxxxxxx> > > 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. -- 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
