From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 3 of 3] libxl: make it possible to explicitly specify default sched params Date: Wed, 23 May 2012 23:19:35 +0200 Message-ID: <1337807975.25349.9.camel@Abyss> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1223401612688068231==" 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: George Dunlap Cc: Ian.Jackson@citrix.com, Juergen Gross , xen-devel@lists.xen.org, Ian Campbell , George.Dunlap@citrix.com List-Id: xen-devel@lists.xenproject.org --===============1223401612688068231== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UIosw9EP3qoSitp5S17F" --=-UIosw9EP3qoSitp5S17F Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-05-23 at 20:28 +0100, George Dunlap wrote:=20 > Overall the idea of the patch looks good. There's just the thing > about shoving all the various schedulers' parameters into one struct. > Yep, I really don't like that either. > One fall-out from it is that if you specify weight in your config file > (or during domain creation), it will set the weight for credit or > credit2, but use the defaults for sedf. This might be nice; but we're > implicitly baking in an assumption that parameters with the same name > have to have roughly similar meanings across all schedulers. > Furthermore, if someone sets a "cap" in the config file, for example, > but starts the VM in a pool running credit2, should we really just > silently ignore it, or should we alert the user in some way? >=20 I agree... Some mechanism for providing the user at least with a warning would be useful. > In any case, this patch only takes things half-way. If we're really > going to have One Struct to Rule Them All, we don't need different > domain_set/domain_get functions for the different schedulers -- we > just need a libxl_sched_domain_get(), which will both figure out what > scheduler the domain is running, and fill in the appropriate > parameters, and a libxl_sched_domain_set(), which will check to see > that you've asked for the right scheduler (or marked "unknown" if you > aren't afraid), and set what it can set. =20 > According to my personal taste, that would be quite ugly, not to mention that every time we might be adding/removing/modifying a scheduler, we would need to update this Frankenstein-struct, potentially affecting all the other ones... :-( > I'm not really sure which way I think is best. I can see the > advantage of not having to know which scheduler is actually running, > but I'm a bit wary of baking in assumptions about the equivalence of > parameters; it seems like it could lead to some nasty surprises. >=20 I agree again: the fact that, right now, _almost_ all the existing schedulers have a parameter called weight with _almost_ the same meaning shouldn't allow us to assume that to be true now and forever. > But I think whichever way we choose, we should take it to its logical > conclusion. Which in the "One Struct" way, would mean having a single > domain_get/domain_set function, and in the "separate struct" way would > probably mean specifying the scheduler -- i.e., "credit_weight", > "credit2_weight" or something like that. (Obviously we need xm > compatibility, but we can throw a warning to encourage people to > change their config files.)=09 >=20 For what it counts, I'm all for option #2, i.e., each scheduler with its own struct, set of helper functions, xl sub-command, etc. Something like 'credit.cap =3D XX', 'credit2.weight =3D XX' or 'sedf.period =3D XXX' would= be nice, for discriminating them in the config file. It'd remain to decide what to do with things like 'weight =3D XX', which we need to support for backward compatibility, but I guess almost anything is fine, provided we warn the user about what's happening and ask him to update the syntax. Just my 2 cents. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-UIosw9EP3qoSitp5S17F 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAk+9VGcACgkQk4XaBE3IOsTMZwCghlRuIQoxNkMnPKhWMrFL8ICq Y1UAoKpJ8FjMcvqxrRWoKiLXkxYAIZkg =8Kkt -----END PGP SIGNATURE----- --=-UIosw9EP3qoSitp5S17F-- --===============1223401612688068231== 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 --===============1223401612688068231==--