From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Notes on stubdoms and latency on ARM Date: Thu, 20 Jul 2017 10:49:36 +0200 Message-ID: <1500540576.20438.4.camel@citrix.com> References: <8c63069d-c909-e82c-ecba-5451f822a5cc@citrix.com> <1497953518.7405.21.camel@citrix.com> <1499445690.3620.8.camel@citrix.com> <1499840091.7756.12.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3955160033075757025==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , Stefano Stabellini , Volodymyr Babchuk Cc: Artem_Mygaiev@epam.com, Julien Grall , xen-devel@lists.xensource.com, Andrii Anisov List-Id: xen-devel@lists.xenproject.org --===============3955160033075757025== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-Om6lGwywtBKAsQ02uSkP" --=-Om6lGwywtBKAsQ02uSkP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2017-07-17 at 10:25 +0100, George Dunlap wrote: > On 07/12/2017 07:14 AM, Dario Faggioli wrote: > >=20 > > That being said, I personally have never liked rate-limiting, it > > always > > looked to me like the wrong solution. >=20 > 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. >=20 It has been introduced because SpecVirt perf were bad because, during interrupt storms, the context-switch rate was really really high. It was all about Credit1... Work on Credit2 was stalled at the time, and there has been, AFAICR, no evaluation of Credit2 was involved: https://wiki.xen.org/wiki/Credit_Scheduler#Context-Switch_Rate_Limiting https://lists.xenproject.org/archives/html/xen-devel/2011-12/msg00897.html%= 7C (And in fact, it was not implemented in Credit2, until something like last year, Anshul wrote the code for that.) SpecVirt performance were judged to be important enough (e.g., because we've been told people was using that for comparing us with other virt. solutions), that this was set to on by default.=20 I don't know if that is still the case, as I've run many benchmarks, but never had the chance to try SpecVirt first hand myself. Fact is that Credit1 does not have any measure in place for limit/control context-switch rate, and it has boosting, which means that rate- limiting (as much as I may hate it :-P) is actually useful. Whether we should have it disabled by default, and tell people (in documentation) to enable it if they think they're seeing the system going into trashing because of context switching, or the vice-versa, it's one of those things which is rather hard to tell. Let's see... In Credit2, we do have CSCHED2_MIN_TIMER (which is not equivalent to ratelimiting, of course, but it at least is something that goes in the direction of trying to avoid too frequent interruptions), and (much more important, IMO) we don't have boosting... So, I think it would be interesting to try figuring out the role that rate-limiting plays, when Credit2 is in use (and then, maybe, if we find that there are differences, find a way to have, as default, it enabled on Credit1 and disabled on Credit2). > > I'll think about it, and see if I'll be able to run some benchmarks > > with it on and off. >=20 > Thanks.=C2=A0=C2=A0FYI the main benchmark that was used to justify its > inclusion > (and on by default) was specvirt (I think). >=20 Yeah, I know. I'm not sure I will have the chance to run that soon, though. I'll try a bunch of other workloads, and we'll see what I will find. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Om6lGwywtBKAsQ02uSkP 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 v2 iQIcBAABCAAGBQJZcG6hAAoJEBZCeImluHPucUgP+QHf3Mzp8AW9Mc4Jt1dWcjfq quE4yrWV8xgp5qVQBjXM4DzoyxOh+klQwSzz+Y+7fShSSGDNgIJ6pCxuHL0UucMw H6XZesPH8vGKhcAhCayG/sKlBVWwbvye/POvB/kkymzr/0Jn2SfRkNUH5lHGxNDK LJBstILduWcyZgrsTdqNWrwm66vCUSNcYgrE7y588TCt7V9BRBldcnQ4aqH/UAdf xBk4vqQUTCjtCmTiyIlEE/OUyk3CulmSdwbx81OJzQojzcEIIDgN0lA/HEdT4c7N zmZJkfwRHZLPMRaTpyPVuuG58mjfk9yd3X5M66BegMOaAuTUMk2OuU+J8sXG+xrg ff1Dm5JWZsQoxUe4DBSvxA9/HB6h6u60vtersMH6FleGLnPhBIRgcypm6j7F5owN dtK6k8N45Gx994z+ApF+FJvLjWi7Rq+/GCDve26MaI+PsqjhFns/nLWTXI+oPdqI jiNO3SHkOb1CVtIO+UOrRbFX5R3MIcPUsqoiSwkX44P2wiMdqQShKQYEMeT5YEqR hwcQRy1SphUi1B/tXWU7hcbsfgEk6pPqt6qYqekFnAB3HHNKLJN17QepvNfpSgJq kl3KQhPnVGWSZz54pVGM50nYd6s0pmbKcl9SV8zQ9Dbd5AwCISHIWHXQsPT35aOM YTXVuxVKcJtUY+elj6ss =fVrx -----END PGP SIGNATURE----- --=-Om6lGwywtBKAsQ02uSkP-- --===============3955160033075757025== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3955160033075757025==--