On Sat, Apr 28, 2018 at 02:54:36AM +0200, Paolo Bonzini wrote:
On 25/04/2018 16:07, Anthoine Bourgeois wrote:
The root cause of the problem is starting hrtimer with an expiry time
already in the past can take a long time to trigger the timer function.
It can be solved by executing such past timers immediately, rather than
submitting them to hrtimer_start().
The change makes more sense now indeed, but I would like an explanation
of one thing: what is "a long time" and why does it cause the issue?
What period is used by Windows?
A long time is more than 15-20 milliseconds compare to 3-5 microseconds.
I don't know what cause the issue but watching the code in the
schedulers I saw that they always check the expire before submit it.
Maybe it's a known behavior of the hrtimer API.
The period used by Windows change over time but it can be 1 milliseconds
or less. I saw the limit_periodic_timer_frequency print so 500
microseconds is sometimes reached.
Code-wise, just a simple change:
@@ -1537,6 +1520,26 @@ static bool set_target_expiration(struct kvm_lapic *apic)
return true;
}
+static void start_sw_period(struct kvm_lapic *apic)
+{
+ if (!apic->lapic_timer.period)
+ return;
+
+ if (ktime_after(ktime_get(),
+ apic->lapic_timer.target_expiration)) {
+ apic_timer_expired(apic);
+
+ if (apic_lvtt_oneshot(apic))
+ return;
+
+ set_target_expiration(apic);
This last line should be
advance_periodic_target_expiration(apic);
(a simpler version of set_target_expiration).
Thank you. Your version of the patch is tested and I'll send an updated
version of the patch soon.
Could the patch be backport to stable ?
Anthoine
