From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Delays on usleep calls Date: Fri, 24 Jan 2014 18:08:24 +0100 Message-ID: <1390583304.3869.182.camel@Solace> References: <1390230336.23576.24.camel@Solace> <1390304761.23576.161.camel@Solace> <1390327005.23576.219.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2924601876300090027==" 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 --===============2924601876300090027== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MxdYYiuWOreRh7IytDbq" --=-MxdYYiuWOreRh7IytDbq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2014-01-23 at 21:09 +0200, Pavlo Suikov wrote: > Hi Dario, >=20 > > Can I ask how the numbers (for DomU, of course) looks like now? >=20 >=20 > They are all 31 ms, so minimal overhead is achieved. However, it looks > like we still have some gremlins in there: from boot to boot this time > can change to 39 ms. So without Xen scheduler being active sleep > latency stabilizes, but not always on a correct value. >=20 Wow... So, you're saying that, with the DomU exclusively pinned to a specific pCPU, latency is stable, but the value at which it stabilizes varies from boot to boot? That's very weird... > > 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 >=20 >=20 > Yeah, we have tried this as well and it gives us almost the same > result as in previous case: sleep latency in dom0 is not present, so > we get 30 to 31 ms on 30 ms sleep without any variations. >=20 Ok. Are you aware of xentrace and xenalyze? Have, for example, a look here: http://blog.xen.org/index.php/2012/09/27/tracing-with-xentrace-and-xenalyze= / Perhaps you could, in this Dom0 case, you can start the tracing, start the DomU and then run the experiments. It's going to be though to correlate the actual activity in Dom0 (the test running inside it), with the Xen's traces, but at least you should be able to see when, and try to figure out why, the DomU, which should be just idle, ends up getting in your way. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-MxdYYiuWOreRh7IytDbq 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 iEYEABECAAYFAlLinggACgkQk4XaBE3IOsQ6mwCdGrPo0COsGGYh2kSMscPFllVW lRUAn2kAS8842ZKPpPYy75Az+oi0xZ3b =PLTk -----END PGP SIGNATURE----- --=-MxdYYiuWOreRh7IytDbq-- --===============2924601876300090027== 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 --===============2924601876300090027==--