From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC v1 3/4] libxl for rt scheduler Date: Mon, 14 Jul 2014 12:38:50 +0200 Message-ID: <1405334330.29306.629.camel@Solace> References: <1405054198-29106-1-git-send-email-mengxu@cis.upenn.edu> <1405054198-29106-4-git-send-email-mengxu@cis.upenn.edu> <1405091329.29306.464.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1807086365942115439==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Meng Xu Cc: "ian.campbell@citrix.com" , "xisisu@gmail.com" , "stefano.stabellini@eu.citrix.com" , "george.dunlap@eu.citrix.com" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Meng Xu , "lichong659@gmail.com" , "dgolomb@seas.upenn.edu" List-Id: xen-devel@lists.xenproject.org --===============1807086365942115439== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aVxw8XftkPgKhZ2IlMbK" --=-aVxw8XftkPgKhZ2IlMbK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On sab, 2014-07-12 at 14:16 -0400, Meng Xu wrote: >=20 > You well can define both to the same value, of course. > =20 > As per the value, yes, even if we turn the interface in usecs, > 2^32 > usecs is still ~4000 secs, which ought to be enough as a > period or > budget for everyone! :-) > =20 >=20 >=20 > Actually, I'm not very sure about the range (max value) for the xl > sched-rt interface now: I will change the type of period and budget in > Xen to s_time_t which is signed long (64bits). (I can also change the > type of period and budget in tool to be 64bits) >=20 In libxc, you probably should transition to uint64_t, yes. In libxl, you probably will have to use 'integer', as sedf does: libxl_domain_sched_params =3D Struct("domain_sched_params",[ ("sched", libxl_scheduler), ("weight", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT= _DEFAULT'}), ("cap", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_CAP_DE= FAULT'}), ("period", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_PERIOD= _DEFAULT'}), ("slice", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_= DEFAULT'}), ("latency", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_LATENC= Y_DEFAULT'}), ("extratime", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_EXTRAT= IME_DEFAULT'}), ]) > My question is: > Do we really need to do this range check and set the max value of the > xl sched-rt to (2^64 - 1)/1000 (us)? (64 bits can have 2^61-1 ns, so > it's (2^64-1)/1000 us) > If we look at the actually range value (2^64-1)/1000 ns, it's equal to > 5.8*10^11 years, which is too large to be realistic.=20 >=20 I concur. It's quite hard to decide what is a sane upper bound for period and budget, as user may want to try doing all kind of crazy stuff! :-O For sure, if we want to put an upper bound, it has to come from some reasoning about the scheduler's usage, rather than from limitations coming from the actual type used (which makes sense, actually). If, for instance, you keep 2^32 (no matter whether you use 32 or 64 bits), you end up with, if I've done the math correctly, a bit more than 1 hour period and budget, which I think is fine, do you? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-aVxw8XftkPgKhZ2IlMbK 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 iEYEABECAAYFAlPDszoACgkQk4XaBE3IOsQ8tQCfT9Qgrc38h43VCWhLD1hqx1UG PREAoKFrnrjtdsU4sF7nBRuDdL2ZLZ8O =zpxk -----END PGP SIGNATURE----- --=-aVxw8XftkPgKhZ2IlMbK-- --===============1807086365942115439== 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 --===============1807086365942115439==--