Re: Delays on usleep calls

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2842 bytes --]

On mar, 2014-01-21 at 17:53 +0200, Pavlo Suikov wrote:

> It happened that we cannot start dom0 with one vCPU (investigation on
> this one is still ongoing), 
>
Oh, I see. Weird.

> but we succeded in giving one vCPU to domU and pinning it to one of
> the pCPUs. Interestingly enough, that fixed all the latency observed
> in domU.
> 
Can I ask how the numbers (for DomU, of course) looks like now?

> # xl vcpu-list 
> Name                                ID  VCPU   CPU State   Time(s) CPU
> Affinity
> Domain-0                             0     0    0   ---      38.6  0
> Domain-0                             0     1    0   r--      31.8  0
> android_4.3                          1     0    1   b     230.2  1
> 
> 
> In dom0 (which has two vCPUs, so Xen scheduling is actually used)
> latency is still present.
> 
Did you try reducing the scheduling timeslice to 1ms (or even something
bigger, but less than 30)? If yes, down to which value?

Another thing I'll try, if you haven't done that already, is as follows:
 - get rid of the DomU
 - pin the 2 Dom0's vCPUs each one to one pCPU
 - repeat the experiment

If that works, iterate, without the second step, i.e., basically, run
the experiment with no pinning, but only with Dom0.

What I'm after is, since you report DomU performance are starting to be
satisfying if pinning is used, trying to figure out whether that is the
case for Dom0 too, as it should be, or if there is something interfering
with that. I know, if the DomU is idle when running the load in Dom0,
having it or not should not make much difference, but still, I'd give
this a try.

> So without virtualization of CPUs for domU soft real time properties
> with regard to timers are met (and our RTP audio sync is doing much
> better). That's obviously not a solution, but it shows that Xen credit
> (and sEDF) scheduling is actually misbehaving on such tasks and there
> is an area to investigate.
> 
Yes. Well, I think it says that, at least for your usecase, the latency
introduced by virtualization per se (VMEXITs, or whatever is the ARM
equivalent for them, etc) are not showstoppers... Which is already
something! :-)

What we now need to figure out, is with what scheduler(s) and, for that
(each) scheduler(s), with what parameters, that property is preserved.
And, I agree, this is something to be investigated.

> I will keep you informed when more results are present, so stay
> tuned :)
> 
Thanks for all the updates so far... I definitely will stay tuned. :-)

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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