From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC/RFT][PATCH 1 of 3] Move locking into pluggable schedulers. Date: Wed, 23 Nov 2011 18:09:29 +0100 Message-ID: <1322068169.26883.35.camel@Solace> References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss> <1322065473.1005.151.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8061296350353117102==" Return-path: In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: George Dunlap , Juergen Gross , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org --===============8061296350353117102== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-b2p6OwMVVfDgkYxiBe9M" --=-b2p6OwMVVfDgkYxiBe9M Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote: > > struct csched_private { > > + /* lock for the whole pluggable scheduler, nests inside cpupool_lo= ck */ > > spinlock_t lock; > > struct list_head active_sdom; > > uint32_t ncpus; >=20 > Given that every scheduler plugin is going to need this lock perhaps it > could be provided globally (but still have the responsibility for using > it fall on the plugin)? >=20 Makes sense to me, and it should be something pretty easy to do, if you were thinking of just moving the lock to general code. I'm saying this because both credit and credit2 has much more payload in their `struct csched_private', and if we also want to get rid of the struct for them as well, that would be a different story! :-) > I was mainly thinking of the sedf case where you add and maintain the > whole structure for just that lock. Perhaps you have future plans which > involve having to do that anyway in which case maybe my suggestion > doesn't make sense. > I know and I agree, that 1-field-struct is just as ugly as hell! Reason why I went for it are homogeneity with the current code of all the schedulers, and yes, also, what you're saying above, i.e., it might turn useful in future to have some scheduler-wide repository in sedf as it is now for credit*. But no, I don't have _specific_ plans yet, so your comment do make sense. Anyway, even if we'd stay with what's in this patch, I think this at least need some commenting... Thanks and Regards, Dario --=20 <> (Raistlin Majere) ------------------------------------------------------------------- Dario Faggioli, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy) --=-b2p6OwMVVfDgkYxiBe9M 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.11 (GNU/Linux) iEYEABECAAYFAk7NKMkACgkQk4XaBE3IOsR4kQCggdxArIZwLSu69FHgSkj+GaS5 lJIAoKPhb3fXn/v026WNpn34tgWPFMWU =MH6R -----END PGP SIGNATURE----- --=-b2p6OwMVVfDgkYxiBe9M-- --===============8061296350353117102== 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.xensource.com http://lists.xensource.com/xen-devel --===============8061296350353117102==--