From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 3/4] libxl: add rtds scheduler Date: Wed, 17 Sep 2014 12:19:57 +0200 Message-ID: <1410949197.3531.113.camel@Solace.lan> References: <1410730649-2417-1-git-send-email-mengxu@cis.upenn.edu> <1410730649-2417-4-git-send-email-mengxu@cis.upenn.edu> <1410818821.6908.4.camel@hastur.hellion.org.uk> <1410832163.6908.36.camel@hastur.hellion.org.uk> <1410852450.20720.10.camel@Abyss> <1410886482.23505.19.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2812542439798302724==" Return-path: In-Reply-To: <1410886482.23505.19.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Sisu Xi , Stefano Stabellini , George Dunlap , Chenyang Lu , Ian Jackson , "xen-devel@lists.xen.org" , Linh Thi Xuan Phan , Meng Xu , Meng Xu , Jan Beulich , Chao Wang , Chong Li , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============2812542439798302724== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fPGe+U7uDBz54s1Btmyv" --=-fPGe+U7uDBz54s1Btmyv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2014-09-16 at 17:54 +0100, Ian Campbell wrote: > On Tue, 2014-09-16 at 09:27 +0200, Dario Faggioli wrote: > > On Mon, 2014-09-15 at 23:32 -0400, Meng Xu wrote: > >=20 > > > 2014-09-15 21:49 GMT-04:00 Ian Campbell : > >=20 > > > Is a 0.5hr maximum period considered to be larger than any > > > practically > > > useful value? > > >=20 > > >=20 > > > I think so.=20 > > > > > Yes, it is. Most of the people using this scheduler will be interested > > in "a few [decades, hundreds] millisecond" period and budget. Someone > > might want to try microsecs, someone may be fine with seconds. >=20 > OK, so no need for me to ask if it should be a 64bit value then. >=20 It actually was. Then Jan asked whether it really needed to be, and we all agreed it did not. TBF, what we were talking in tha thread was the xc and hv interface. Nothing forbids the two interfaces to differ in the types of this field, I think. I guess the question here is whether we would like, at the libxl level, to be a bit, let's say, 'less strict'. That would mean, e.g., using something like int64 or uint64 in libxl (type declarations and all the related functions), and then do some range checking, in the libxl implementation, before passing down the values to libxc. That would be because, while libxc and Xen interface can change, libxl should not. One possible reason could be, for example, if we at some point will want for the budget and period to be specified in ns, rather than us. Honestly, I don't foresee such a thing becoming any useful, not even in mid or long term future. It is what at least Linux sort of does (POSIX's timespec-s are used, there), though, so it at least is worth some thinking? As I said already, I think this is a fine interface, even with stability in mind, but I'd be fine with a int64_t vesion, here in libxl, if people feels it may be better. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-fPGe+U7uDBz54s1Btmyv 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 iEYEABECAAYFAlQZYE4ACgkQk4XaBE3IOsQDIwCgkwFydFyxzRrosaICMHGIZKBd UYQAnim9HTYbZ+mzUyCUUCZNyBUvr2i7 =6xiF -----END PGP SIGNATURE----- --=-fPGe+U7uDBz54s1Btmyv-- --===============2812542439798302724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2812542439798302724==--