From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Delays on usleep calls Date: Tue, 21 Jan 2014 18:56:45 +0100 Message-ID: <1390327005.23576.219.camel@Solace> References: <1390230336.23576.24.camel@Solace> <1390304761.23576.161.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0868226796670297393==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Pavlo Suikov Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============0868226796670297393== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QEXupiMYfqFJv6DyZ+I8" --=-QEXupiMYfqFJv6DyZ+I8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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),=20 > 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. >=20 Can I ask how the numbers (for DomU, of course) looks like now? > # xl vcpu-list=20 > 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 >=20 >=20 > In dom0 (which has two vCPUs, so Xen scheduling is actually used) > latency is still present. >=20 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. >=20 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 :) >=20 Thanks for all the updates so far... I definitely will stay tuned. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-QEXupiMYfqFJv6DyZ+I8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlLetN0ACgkQk4XaBE3IOsR9jQCfb4kKzzn7IBfRKkii/2KLlU1U eZ0AnRh+nDvEQWCM5kNjgRJEfdTJwKf5 =Mc+L -----END PGP SIGNATURE----- --=-QEXupiMYfqFJv6DyZ+I8-- --===============0868226796670297393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0868226796670297393==--