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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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