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

2015-01-08 Thread Paolo Bonzini
On 08/01/2015 18:41, Marcelo Tosatti wrote: Paolo? And cover letter is a bit misleading: The condition does nothing to guarantee TSC based __delay() loop. (Right now, __delay() = delay_tsc() whenever the hardware has TSC, regardless of stability, thus always.) OK. Yes, because of

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

2015-01-08 Thread Marcelo Tosatti
On Mon, Jan 05, 2015 at 07:12:36PM +0100, Radim Krcmar wrote: 2014-12-23 15:58-0500, Marcelo Tosatti: 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

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

2015-01-05 Thread Radim Krcmar
2014-12-23 15:58-0500, Marcelo Tosatti: 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

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

2015-01-05 Thread Radim Krcmar
2015-01-05 19:12+0100, Radim Krcmar: (Right now, __delay() = delay_tsc() whenever the hardware has TSC, regardless of stability, thus always.) (For quantifiers' sake, there also is 'tsc_disabled' variable.) -- To unsubscribe from this list: send the line

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

2014-12-23 Thread Paolo Bonzini
On 18/12/2014 13:24, Marcelo Tosatti wrote: True. I can change to a direct wait if that is preferred. What about this: guest_tsc = kvm_x86_ops-read_l1_tsc(vcpu, native_read_tsc()); trace_kvm_wait_lapic_expire(vcpu-vcpu_id, guest_tsc - tsc_deadline); /* We know that

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

2014-12-23 Thread Marcelo Tosatti
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

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

2014-12-18 Thread Marcelo Tosatti
On Wed, Dec 17, 2014 at 08:36:27PM +0100, Radim Krcmar wrote: 2014-12-17 15:41-0200, Marcelo Tosatti: On Wed, Dec 17, 2014 at 03:58:13PM +0100, Radim Krcmar wrote: 2014-12-16 09:08-0500, Marcelo Tosatti: + tsc_deadline = apic-lapic_timer.expired_tscdeadline; +

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

2014-12-17 Thread Radim Krcmar
2014-12-16 09:08-0500, Marcelo Tosatti: 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

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

2014-12-17 Thread Marcelo Tosatti
On Wed, Dec 17, 2014 at 03:58:13PM +0100, Radim Krcmar wrote: 2014-12-16 09:08-0500, Marcelo Tosatti: 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

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

2014-12-17 Thread Paolo Bonzini
On 17/12/2014 18:41, Marcelo Tosatti wrote: Btw. simple automatic delta tuning had worse results? Haven't tried automatic tuning. So what happens on a realtime environment is this: you execute the fixed number of instructions from interrupt handling all the way to VM-entry. Well,

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

2014-12-17 Thread Radim Krcmar
2014-12-17 15:41-0200, Marcelo Tosatti: On Wed, Dec 17, 2014 at 03:58:13PM +0100, Radim Krcmar wrote: 2014-12-16 09:08-0500, Marcelo Tosatti: + tsc_deadline = apic-lapic_timer.expired_tscdeadline; + apic-lapic_timer.expired_tscdeadline = 0; + guest_tsc = kvm_x86_ops-read_l1_tsc(vcpu,

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

2014-12-16 Thread Marcelo Tosatti
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

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

2014-12-16 Thread Paolo Bonzini
On 15/12/2014 23:06, Marcelo Tosatti 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

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

2014-12-16 Thread Marcelo Tosatti
On Tue, Dec 16, 2014 at 03:34:22PM +0100, Paolo Bonzini wrote: On 15/12/2014 23:06, Marcelo Tosatti 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.

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

2014-12-16 Thread Paolo Bonzini
On 16/12/2014 16:13, Marcelo Tosatti wrote: So perhaps you can get rid of patch 1 and check kvm_apic_vid_enabled(vcpu-kvm): if (k_a_v_e(vcpu-kvm) return true; if (apic_test_vector(vec, apic-regs + APIC_ISR)) return true; Does this sound correct? *

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

2014-12-15 Thread Marcelo Tosatti
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