From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS Date: Fri, 4 Aug 2017 10:13:18 +0200 Message-ID: <1501834398.28477.14.camel@citrix.com> References: <1501612434-5803-1-git-send-email-mengxu@cis.upenn.edu> <1501612434-5803-3-git-send-email-mengxu@cis.upenn.edu> <1501775614.28477.10.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3193405006959989325==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddXjf-0002lh-Rz for xen-devel@lists.xenproject.org; Fri, 04 Aug 2017 08:13:31 +0000 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 , "xen-devel@lists.xenproject.org" , Ian Jackson , Wei Liu List-Id: xen-devel@lists.xenproject.org --===============3193405006959989325== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-kBQ+062AlLjgjOxF1gF1" --=-kBQ+062AlLjgjOxF1gF1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-08-03 at 17:39 -0400, Meng Xu wrote: > On Thu, Aug 3, 2017 at 11:53 AM, Dario Faggioli > wrote: > >=20 > > How about, here at libxl level, we use the "extratime" field that > > we > > have as a leftover from SEDF (and which had, in that scheduler, a > > similar meaning)? > >=20 > > If we don't want to use that one, and we want a new field, I > > suggest > > thinking to a shorter name. >=20 > How about 'LIBXL_DOMAIN_SCHED_PARAM_FLAG'? > We use a bit in the flag field in the sched_rt.c to indicate if a > VCPU > is work-conserving.=20 > This is entirely in the hands of tools maintainers, especially considering this is the libxl API. In general, yes, for the same reasons I suggested using flags in both Xen interface and implementation, I also like using flags here.=20 *HOWEVER*, in this case, we do have that 'extratime' field already, as a leftover from SEDF, which is there taking space and cluttering the interface, so why don't make good use of it. Especially considering it was used for _exactly_ the same thing, and with _exactly_ the same meaning, and even for a very similar (i.e., SEDF was also real-time) kind of scheduler. Also, note that Xen interface and libxl API are different, and the same concepts, does not necessarily have to be used in lockstep. It may or may not be the best/easies/whatever thing to actually do, but on a case by case basis. IAC, final say is Wei's and Ian's, and although I do have a preference, which I voiced, I'm totally fine with whichever between the two approaches they advise us to take. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-kBQ+062AlLjgjOxF1gF1 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 iQIcBAABCAAGBQJZhCyeAAoJEBZCeImluHPuK+gP/R7yIZTEW7SmyrlS10bCImjx XxLDOgmm4FvRnaEN4F/54eWd5PNdGEPrG3LEco/TGx/qppd6e0wIn4EoorLZ1dEZ JGCJt4/3f9UtjuwsAnXoo5KwyXrlreC2mEUv7P3MvRASAox9SAUghfFj/RMdBMUj kSU1xLp1xEA7kDh+79nSo4mKAJQA+4NKjF/XmvDSnfqtNSJo0RS4YsJSqdlrBBYd ctA0RYRM4vBMBcnF4j1toZ4MHlL7QjnqfVupCQz+tepv7bzPPD4JiNtWm0qkUtuy vzkmrsWIlvQ5DV09QngFjMYXiFURStD0eSOjUtQwSyz3WezXMNJID4wiwDODoAZo 17BFJfW+0H0w+QjeZEdbKJn9TAK/hf/gkh4tkp7YcD6IljxvKEA210YtHig9PKI2 aCti+43Hj0PdqNW9oDiHL+fMqwT8X5dLR0cWQwwmfq/2CEoj1iFzVft7SeT2FdwG NfO6piumiHiCVBu6HlY2QtsCGr3Z2vqZq1Kyug3haLOBnQsawgTzAG3drOGzDV3A kJXGQyBcVqnKa+36QOGJhVKgMtnyzUHL4xH/zbZfLB3B4nyF5t4OZkmI8Lkl65/C 6102lxIZ24EIfkbTrYDZU4/sK+W09cGbd6FkDwuXYrbprjRTPGqmQEdYwmjXSB4W EPtfBMStNqlNOqtuzQRL =2YP3 -----END PGP SIGNATURE----- --=-kBQ+062AlLjgjOxF1gF1-- --===============3193405006959989325== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3193405006959989325==--