[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

On 17/07/17 10:25, George Dunlap wrote:
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.

FWIW, we don't yet parse the pCPU topology on ARM. AFAIU, we always tell Xen each CPU is in its own core. Will it have some implications in the scheduler?

Cheers,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.