Re: [Xen-devel] Delays on usleep calls

[Pavlo Suikov <pavlo.suikov@xxxxxxxxxxxxxxx>]

Hi,

> Ok, so, if, as said above, you can do that, I'd try the following. With
> the credit scheduler (after having cleared/disabled the rate limiting
> thing), go for 1 vCPU in Dom0 and 1 vCPU in DomU.

> Also, pin both, and do it to different pCPUs. I think booting with this
> "dom0_max_vcpus=1 dom0_vcpus_pin" in the Xen command line would do the
> trick for Dom0. For DomU, you just put in the config file a "cpus=X"
> entry, as soon as you see what it is the pCPU to which Dom0 is _not_
> pinned (I suspect Dom0 will end up pinned to pCPU #0, and so you should
> use "cpus=1" for the DomU).

> With that configuration, repeat the tests.

It happened that we cannot start dom0 with one vCPU (investigation on this one is still ongoing), 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.

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

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.

I will keep you informed when more results are present, so stay tuned :)

Regards, Pavlo

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