Re: [Xen-devel] Notes on stubdoms and latency on ARM

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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.

> 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.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel