On Sun, 2019-03-24 at 14:07 -0400, Boris Ostrovsky wrote: > On Sat, Mar 23, 2019 at 08:00:52AM -0400, Ryan Thibodeaux wrote: > > This test system was configured to use a TSC clocksource, disabled > > C states, and lowered the timer slop. I am not claiming the timer > > slop change was solely responsible for the best results. > > How can we then be sure that the proposed change will indeed provide > some sort of benefit? > > Were there any other changes between your tests to think that slop > time modification may not be responsible for better results? > FWIW, in mine and Luca's experiments, changing lowering both timer_slop in Xen and TIMER_SLOP in Linux, improved latency dramatically, without any other change. We also tried _only_ playing with the Xen tunable (as there's a Xen boot parameter for it already) but that wasn't enough. It was only when we also tuned TIMER_SLOP in Linux's Xen clockevent device that we got decent numbers (i.e., comparable to KVM ones). Reason why we had not share these results yet was that we were still "polishing" them, and because we also found a couple of other issues, and we were trying to understand them better, before sending anything out. But those other issues were --although still about achieving low latencies-- orthogonal from this, and lowering the default slop is absolute prerequisite for even talking about having a reasonable vcpu response time. A patch like this one, was something we were thinking to submit ourself sooner or later (backed up by our results). Personally, in addition to making the value tunable, which I think is a good thing, I also would lower the default. Regards, Dario -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/