On 29/04/2018 23:10, Anthoine Bourgeois wrote: > 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. Yeah, if you want to change that to 200 that's also okay. Windows 10 changed the scheduler tick limit from 1024 Hz to 2048 Hz, so 200 ms (5000 Hz) leaves some headroom. > 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 ? Yes, of course - that's also why I wanted some clarifications to the commit message. Thanks, Paolo
