From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Notes on stubdoms and latency on ARM Date: Tue, 23 May 2017 09:11:45 +0200 Message-ID: <1495523505.7393.59.camel@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6084746057762172380==" 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: Volodymyr Babchuk , Stefano Stabellini Cc: Artem_Mygaiev@epam.com, Julien Grall , xen-devel@lists.xensource.com, Andrii Anisov , George Dunlap List-Id: xen-devel@lists.xenproject.org --===============6084746057762172380== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-0MUrYg0yZX+As5ySYPxK" --=-0MUrYg0yZX+As5ySYPxK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2017-05-19 at 22:45 +0300, Volodymyr Babchuk wrote: > On 18 May 2017 at 22:00, Stefano Stabellini > wrote: > > ACTIONS: > > Improve the null scheduler to enable decent stubdoms scheduling on > > latency sensitive systems. >=20 > I'm not very familiar with XEN schedulers.=20 > Feel free to ask anything. :-) > Looks like null scheduler > is good for hard RT, but isn't fine for a generic consumer system.=20 > The null scheduler is meant at being useful when you have a static scenario, no (or very few) overbooking (i.e., total nr of vCPUs ~=3D nr of pCPUS), and what to cut to _zero_ the scheduling overhead. That may include certain class of real-time workloads, but it not limited to such use case. > How > do you think: is it possible to make credit2 scheduler to schedule > stubdoms in the same way? >=20 It is indeed possible. Actually, it's actually in the plans to do exactly something like that, as it could potentially be useful for a wide range of use cases. Doing it in the null scheduler is just easier, and we think it would be a nice way to quickly have a proof of concept done. Afterwards, we'll focus on other schedulers too. > > Investigate ways to improve context switch times on ARM. >=20 > Do you have any tools to profile or trace XEN core? Also, I don't > think that pure context switch time is the biggest issue. Even now, > it > allows 180 000 switches per second (if I'm not wrong). I think, > scheduling latency is more important. >=20 What do you refer to when you say 'scheduling latency'? As in, the latency between which events, happening on which component? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-0MUrYg0yZX+As5ySYPxK 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 iQIcBAABCAAGBQJZI+C0AAoJEBZCeImluHPuFVQQAJA3+6guaEdC2Xf4GGRuSps7 Cd95RTHy9VL92RQaxV2ay+XG1nXZ2ge6pHJT+QHDTmAk3gxjdFPGXrRqjXEevwyN Ztc0Hfj/NYzTfimxvqqh8LPatKNx3oMOAWjCz2faFgZRy5HaRayFe0mkLW8LUKjW zR3VT2F5umITiJ46d7bixtpheBDaUWEf6G/gJOKPtuRNdaPAlOVfd9GSNkbjg2nr +GUMY0pkLeqbcLo+nZBmyJ5gAamLVfp+JmGJNN067+YVYDAQ7AQQYHOYRLu3SIW0 /gJHmiBHmwG4Nv1X8AdZTyST60Si3UiIto9nQiFeQIVPOXGrO0NA03bMTs1+WoHa OlC1WUPAfpJHLuNPJ3dp/1m3sL0tTX3wgIYiZM//bq5trgZ0VrjTZbf4Fy1KDEB+ bt2fIyyRqPrw/iGF0Yg8UF28gIQAB1fnMP9IlHzpNDAcyO3dRs9L6ENvI4z3mm6f OTjJmbW5nkZK5AQCIQCypwe35uRuFqh7fo4h2zwUDOErEaHShEWAd5fp072kTgYU Qk8ZyvtU/iO0CKVqbELBVoLG6Ht2xPyqS3YkW6NAyFDMLGgII8dWYZEPmSWRHXEw QF8rKDJGGoDGoKZlVNKmRi3Zy1ZaM0kx7SEPXsMbXjS+RzdCh53lzfGtbrbgfSB5 WhHOPvt1P8JDE6S3ZJlk =QXmd -----END PGP SIGNATURE----- --=-0MUrYg0yZX+As5ySYPxK-- --===============6084746057762172380== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6084746057762172380==--