[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Notes on stubdoms and latency on ARM
On 07/12/2017 07:14 AM, Dario Faggioli wrote: > On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote: >> On Fri, 7 Jul 2017, Volodymyr Babchuk wrote: >>>>> >>>> Since you are using Credit, can you try to disable context switch >>>> rate >>>> limiting? >>> >>> Yep. You are right. In the environment described above (Case 2) I >>> now >>> get much better results: >>> >>> real 1.85 >>> user 0.00 >>> sys 1.85 >> >> From 113 to 1.85 -- WOW! >> >> Obviously I am no scheduler expert, but shouldn't we advertise a bit >> better a scheduler configuration option that makes things _one >> hundred >> times faster_ ?! >> > So, to be fair, so far, we've bitten this hard by this only on > artificially constructed test cases, where either some extreme > assumption were made (e.g., that all the vCPUs except one always run at > 100% load) or pinning was used in a weird and suboptimal way. And there > are workload where it has been verified that it helps making > performance better (poor SpecVIRT results without it was the main > motivation having it upstream, and on by default). > > That being said, I personally have never liked rate-limiting, it always > looked to me like the wrong solution. In fact, I *think* the only reason it may have been introduced is that there was a bug in the credit2 code at the time such that it always had a single runqueue no matter what your actual pcpu topology was. >> It's not even mentioned in >> https://wiki.xen.org/wiki/Tuning_Xen_for_Performance! >> > Well, for sure it should be mentioned here, you're right! > >> Also, it is worrying to me that there are cases were, unless the user >> tweaks the configuration, she is going to get 100x worse performance >> out >> of her system. >> > As I said, it's hard to tell in advance whether it will have a good, > bad, or really bad impact on a specific workload. > > I'm starting to think, though, that it may be good to switch to having > it off by default, and then document that if the system is going into > trashing because of too frequent context switches, turning it on may > help. > > I'll think about it, and see if I'll be able to run some benchmarks > with it on and off. Thanks. FYI the main benchmark that was used to justify its inclusion (and on by default) was specvirt (I think). -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |