From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC Patch 1/3] Remove sedf extra, weight, and latency parameter support. Date: Mon, 17 Mar 2014 18:02:54 +0100 Message-ID: <1395075774.4159.315.camel@Solace> References: <1394824400-2796-1-git-send-email-nate.studer@dornerworks.com> <1394824400-2796-2-git-send-email-nate.studer@dornerworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7850115022541849310==" Return-path: In-Reply-To: <1394824400-2796-2-git-send-email-nate.studer@dornerworks.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: Nathan Studer Cc: Ian Campbell , Xi Sisu , Stefano Stabellini , George Dunlap , Ian Jackson , Robert VanVossen , xen-devel@lists.xen.org, Joshua Whitehead , Dario Faggioli List-Id: xen-devel@lists.xenproject.org --===============7850115022541849310== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zkfksNcQVTLtJzoR08mO" --=-zkfksNcQVTLtJzoR08mO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2014-03-14 at 15:13 -0400, Nathan Studer wrote: > From: Nathan Studer >=20 > Remove sedf extra, weight, and latency parameters from the scheduler's ad= just > function. Also remove the support for these parameters from the xl tools= tack. >=20 So, from the code point of view, this looks okay, as the rest of the series. My only concern is that, at least extratime and weight, we may need in future, so we'll be removing them here, to reintroduce them in a bit. The reason why I think we could need them back is that, although I concur that work conserving-ness is less important now that there are schedulers much more suitable for general purpose workloads (credit and credit2), it, in my experience, could come handy in real-time scenarios too. However, what the best interface is will only become clear in a while, after the re-design and the re-implementation. Therefore, my take on this would be, let's remove everything, as you're doing in here, and perhaps add what we will end up needing when we will need it/them... which would mean an Ack, from my side, on this patch too. However, since we're discussing interfaces, I'd love to hear what others think. Of course, even if we take the 'kill everything [for now]' route, there's the matter of libxl API stability. So, when it'll come to this, and other libxl API related changes: > index 7d3a62b..1265a73 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -291,8 +291,6 @@ libxl_domain_sched_params =3D Struct("domain_sched_pa= rams",[ > ("cap", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_CAP= _DEFAULT'}), > ("period", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_PER= IOD_DEFAULT'}), > ("slice", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_SLI= CE_DEFAULT'}), > - ("latency", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_LAT= ENCY_DEFAULT'}), > - ("extratime", integer, {'init_val': 'LIBXL_DOMAIN_SCHED_PARAM_EXT= RATIME_DEFAULT'}), > ]) > =20 We'll need the macro tricks to make it safe. For adding fields we usually specify a suitable LIBXL_HAV_FOO symbol... I guess in this case LIBXL_API_VERSION is more suitable? If yes, I'm not sure how it would be best use to affect the actual struct definition, as it originates from the IDL parser... Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-zkfksNcQVTLtJzoR08mO 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.0.22 (GNU/Linux) iEYEABECAAYFAlMnKr4ACgkQk4XaBE3IOsTcEQCff1ZxNMI7K9uXfusvwvV7hQ41 fRQAoKjtRSez+uaHu5jK0Dq3ySAbxcjv =PTRH -----END PGP SIGNATURE----- --=-zkfksNcQVTLtJzoR08mO-- --===============7850115022541849310== 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 --===============7850115022541849310==--