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: Thu, 24 May 2012 11:36:06 +0200 Message-ID: <1337852166.13601.13.camel@Solace> References: <1337807975.25349.9.camel@Abyss> <1337850812.7229.18.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1214648047316160455==" Return-path: In-Reply-To: <1337850812.7229.18.camel@zakaz.uk.xensource.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: George Dunlap , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============1214648047316160455== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-/dKOkYpDrM88Sw+Dh9XW" --=-/dKOkYpDrM88Sw+Dh9XW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-05-24 at 10:13 +0100, Ian Campbell wrote: > On Wed, 2012-05-23 at 22:19 +0100, Dario Faggioli wrote: > > 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. >=20 > I think we reached to opposite conclusion when Deiter implemented the > sched params support, but I don't really mind either way.=20 > Yes, you're thinking right. Unfortunately, besides starting to participate to that thread, I was off when consensus on that particular aspect was reached. After that, I decided it is no such a big deal that would worth a rewrite of the whole thing per-se, but if we are rewriting it anyway, well... :-) > I'm happy to > go with whichever you guys think is best (which seems to be leaning > toward separate structs?). >=20 I am definitely leaning toward that, but of course it's George's opinion the one that we should care most. > > > One fall-out from it is that if you specify weight in your config fil= e > > > (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'r= e > > > 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 warnin= g > > would be useful. >=20 > So xl should query the scheduler for the pool which has been specified > in the config and parse the appropriate options? That seems doable. >=20 That appears right to me, yes. > At the libxl level I think this would end up being a KeyedUnion in the > build info, selecting the appropriate per-sched params struct. Does that > sound reasonable? >=20 To me, definitely. > > For what it counts, I'm all for option #2, i.e., each scheduler with it= s > > own struct, set of helper functions, xl sub-command, etc. Something lik= e > > 'credit.cap =3D XX', 'credit2.weight =3D XX' or 'sedf.period =3D XXX' w= ould 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 f= or > > backward compatibility, but I guess almost anything is fine, provided w= e > > warn the user about what's happening and ask him to update the syntax. >=20 > That all sounds fine, but not for 4.2 IMHO. >=20 Yes, let's just put what xm has together for now, we can add all the other stuff later. 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) --=-/dKOkYpDrM88Sw+Dh9XW 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++AQYACgkQk4XaBE3IOsRzngCfSrf7rZj5OWT/aSF6qyl66YWh NQUAoJGTsRF6V63NDYBgOxx+QhJgq83k =Z1pT -----END PGP SIGNATURE----- --=-/dKOkYpDrM88Sw+Dh9XW-- --===============1214648047316160455== 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 --===============1214648047316160455==--