From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2 0/5] Towards work-conserving RTDS Date: Mon, 2 Oct 2017 19:04:52 +0200 Message-ID: <1506963892.6216.72.camel@citrix.com> References: <1504281532-3766-1-git-send-email-mengxu@cis.upenn.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1082623531927091431==" 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: Andrii Anisov , Meng Xu Cc: xumengpanda@gmail.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============1082623531927091431== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-xwA5A/gvuuBMuJA5AJPa" --=-xwA5A/gvuuBMuJA5AJPa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2017-10-02 at 17:38 +0300, Andrii Anisov wrote: > Hello Meng Xu and Dario, >=20 Hi, > On 01.09.17 18:58, Meng Xu wrote: > > This series of patches make RTDS scheduler work-conserving > > without breaking real-time guarantees. > > VCPUs with extratime flag set can get extra time > > from the unreserved system resource. > > System administrators can decide which VCPUs have extratime flag > > set. >=20 > As I understand from threads and the code, the work conserving > algorithm=20 > is quite simplistic and will prefer a vcpu with greater utilization. >=20 > From our side we are looking for a bit different solution. I.e., in > the=20 > same cpupool, running vcpus eager for RT characteristics under EDF=20 > conditions, and share the rest of resources between non-rt vcpus > (i.e.=20 > in a credit manner). > Possible use-case could be a system with a domain hunger for > resources,=20 > but not critical (some infotainment system) and an RT domain > utilizing=20 > at most 20% of a single CPU core. Having a SoC with 4 cores,=20 > partitioning would be a significant resources wasting for described=20 > scenario. >=20 IMO, this is interesting, but I think the proper way to achieve something like this is not modify RTDS to also contain something like Credit, nor to modify Credit to also contain something like RTDS. The idea I have in mind to serve the use case you're describing is as follows. Right now, a cpupool can only have a scheduler. If it's RTDS, all the domains are scheduler with RTDS, if it's Credit, all the domains are scheduled with Credit, etc. My idea would be to allow a stack of schedulers in a cpupool. Basically, you'd configure a cpupool with sched=3D"rtds,credit2" and then you specify, for each domain, what scheduler you want it to use. The end result would be that, in the example above, domains scheduler with Credit2 would run in the time left free by the domains scheduler by RTDS. E.g., if you have a cpupool with only 1 CPU, an RTDS domain with P=3D100,B=3D20, an RTDS domain with P=3D1000,B=3D40, and two Credit2 domains, one with weight 256 and the other with weight 512. Then, the two RTDS domains will get 20% and 40% of the CPU, while the two Credit2 domains will share the remaining 40% (the one with w=3D512 getting twice as much as the one with w=3D256). This is kind of similar with what Linux does with scheduling classes, but even more flexible. I am not working on implementing this right now, because I'm busy with other things, but I would like to do that at some point. And if you're up for helping, that would be great! :-) Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-xwA5A/gvuuBMuJA5AJPa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAlnScbQACgkQFkJ4iaW4 c+4pZg//UQ97/SyRSRnW3A6IhvL6uUvEmTw1PD6RsPHjBwZ5KGJK8ZJXR9CuhHsM eApLMzrMa8ChLrtGHXduUrL5J56hG0nlF5lUGU9m0gkiRbVevr7FMl3DK5D5nllm w2JrBy/zdD4ldjH+TpH7Qxfp91c/tAiFrOC/l/0XHGQ45OMhuWsGHtVedSC6Irez bwIR+lHYocPzOxtYSpVQLULXNaO0R2Ub6sAV0DyEctCcZwG6oTm4FKsUw0vtXmRJ vMK6NFmYssrmFzVQd2PrNp5lKtLaw4qefWDokep/GLH1eGBXDiKbnbyFtN17c6WG dU+qIeinxmqleFvJcb6WFkcSgEHW4q3Y0hbIF0ND+dGSDr+j1sHTzWOeUkJV/UWO pZfxLolzE4XClMZypJ3GLCi2IdC095bY5Wl6OMWywMNpjJo0gLx8P1FGTOtDjoFH pLI07ghfIc+qHjadtZ8diLrp/CDJ22Nk3ghx/lbaIhjQh4yBG5x1LlRAl3CKxXV+ 68Vt+p1CM/en2PztfPsxsJxkTP1sLzHfNcUqMJToR/g11KscEAt8styKPTXBOPqs ovKwrVn5PZDDWONaI9upaecEp+XA+PSrGns8i+KyWKMy6uu+OCUd4rYi5o3rSevF FyxhPtRLWcHlWHdJNsNnlxqsh09+iEur9XH4RxWeTCqti3r3tBo= =ftfp -----END PGP SIGNATURE----- --=-xwA5A/gvuuBMuJA5AJPa-- --===============1082623531927091431== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1082623531927091431==--