From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v1 3/3] xl: enable per-VCPU extratime flag for RTDS Date: Wed, 9 Aug 2017 00:24:51 +0200 Message-ID: <1502231091.5719.2.camel@citrix.com> References: <1502036563-4275-1-git-send-email-mengxu@cis.upenn.edu> <1502036563-4275-4-git-send-email-mengxu@cis.upenn.edu> <1502208576.18446.17.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9071370351295139441==" 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: Meng Xu Cc: George Dunlap , Ian Jackson , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============9071370351295139441== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-gVpyy+/sOST5rHih0JF3" --=-gVpyy+/sOST5rHih0JF3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-08-08 at 12:16 -0700, Meng Xu wrote: > On Tue, Aug 8, 2017 at 9:09 AM, Dario Faggioli > wrote: > > On Sun, 2017-08-06 at 22:43 -0400, Meng Xu wrote: > > >=20 > > > As to (1), if users want to set some VCPUs with extratime flag > > > set > > > and > > > some with extratime flag clear, there are two types of input: > > > (a) xl sched-rtds -d 1 -v 1 -p 10000 -b 4000 -e 0 -v 2 -p 10000 > > > -b > > > 4000 -e 1 -v 5 -p 10000 -b 4000 -e 0 > > > (b) xl sched-rtds -d 1 -v 1 -p 10000 -b 4000 -v 2 -p 10000 -b > > > 4000 -e > > > 1 -v 5 -p 10000 -b 4000 > > > I felt that the style (a) is more intuitive and the input > > > commands > > > have very static pattern, i.e., each vcpu must have -v -p -b -e > > > options set. > > >=20 > >=20 > > Exactly, I do think that (b) is indeed a better user interface. > >=20 > With the approach (b), what I have in my mind was: if users do not > use > -e option for a vcpu index, the vcpu will have its extratime flag > cleared. > If not-setting -e option for a VCPU means using the current extratime > value for the VCPU, then how should users clear the extratime flag > for > a VCPU?=20 > Yeah, I know... Well, it's an hard interface to get right. So, I think, considering how things currently work for budget and period, I guess I'm fine with the -e switch taking a 0/1 value. I've checked how it was in SEDF, and it was like that in there too (see, e.g. commit 1583cdd1fdded49698503a699c5868643051e391). > If you look at the -p and -b option for the xl sched-rtds, we will > find that users will have to first read both parameters of a VCPU > even > if they only want to change the value for one parameter, either -p or > -b. We don't allow users to specify -p or -b without an input value. >=20 Yes. Which I now remember as something I've never really liked. But again, it's an interface which is a bit hard to get right. And it's certainly not this patch series' job to change it. So, let's stick with it. Thanks for bearing with me. :-) I now want to bring something new on the table, though: what should the default be? I mean, what do we expect most people to want, e.g., at domain creation time, if they don't include an 'extratime=3D1' in their config file (actually, I don't think it's even possible to do that! :-O) ? I believe that --kind of unlikely wrt what happens in the real-time research and papers-- most users would expect a work conserving scheduler, unless they specify otherwise. As in, they hopefully will enjoy being able to reserve some CPU bandwidth in a very precise and deterministic way, for their vCPUs. But I don't think they see as a good thing the fact that those vCPUs stops running at some point, even if the system is idle. Also, I think we really should set dom0 to be in extratime mode. Therefore, I think I would set extratime as on by default in both Xen an xl. What do you think? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-gVpyy+/sOST5rHih0JF3 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 iQIcBAABCAAGBQJZijo0AAoJEBZCeImluHPuzpYP/iw3LpI7epx6QMQ4An4WtDiA 3hdM26L6Ms4Bbzd/ektPeTMDRO+ZpEq1fhwXh47MKq+fhTNL8ZUlGGF8qtpbJiW9 obDhki7YPOKicCaay4rm3lJCNpbTM4USNCPJwsuow9Q8rKGWxFGxT0HhTx+sIb8u 17v8BqSiSPB+ltQxGq44Bgw/goEToZR+JSby90+MNZDNJkItu//uLXGGdG/uCUmx LG3ZGa4OUB1Yu83HnB97dv79SVHg+n14R+o8UPRetrTd6qF1vLTeHU/boQR6lEDn Av50LCy6HahDQY8+CDmOmC2bi6e+LcvXlPn0NR/nSrpE9acyYx57UkTPEPP/dP1+ 8NJ7SJHyGeqxPc69Nf73CL/5rVcrMICHDzP5E0zXfQvbNfj82WUFhOjtRH+vXXQl FrEGpWkdyggATCbsHZZkPhfR39e7O2VE0BmRWbAwKtGrF1swMto2qqdKMHoATYPJ s2zY7t0lZkIfy1tyDMBQbocLnLNtv+T4oGLzC+QFaj1e294iU1HI1T4omOBcmfYy Jzh3Cr2dBvhMsPd93cmsiT9U10VV7PIIVcNXp8sACevMzOtOjBczvstHDBk/agXI 6xgD5PgXoZjt4yaypbjVKNJmbzqNT9i9kNa1komPudx8NL1WAXDjIEjmKFcLHnZB oVcKOWZ+bbckGcZFdC2h =6npZ -----END PGP SIGNATURE----- --=-gVpyy+/sOST5rHih0JF3-- --===============9071370351295139441== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============9071370351295139441==--