From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 2/4] xen: credit2: allow to set and get utilization cap Date: Thu, 29 Jun 2017 12:21:25 +0200 Message-ID: <1498731685.7288.15.camel@citrix.com> References: <149692186557.9605.11625777539060264052.stgit@Solace.fritz.box> <149692373432.9605.11077306237899753280.stgit@Solace.fritz.box> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8574559118164891143==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQWZq-0006SO-7V for xen-devel@lists.xenproject.org; Thu, 29 Jun 2017 10:21:34 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap Cc: xen-devel , Anshul Makkar List-Id: xen-devel@lists.xenproject.org --===============8574559118164891143== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-JiO6u9CXXZw2n4oBtcRr" --=-JiO6u9CXXZw2n4oBtcRr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-06-28 at 16:19 +0100, George Dunlap wrote: > On Thu, Jun 8, 2017 at 1:08 PM, Dario Faggioli > wrote: > >=20 > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0/* > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* We are disabling the cap for this domain, which may > > have vCPUs > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* waiting for a replenishment, and we need to unpark > > them all. > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* Parked vcpus sit in the domain's parked_vcpus list, > > which would > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* require being manipulated with the budget_lock > > held. However, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* we have already disabled budget accounting for all > > the vCPUs of > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* this domain in the loop above, and therefore, no > > vCPU will run > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* out of budget and need being added to the list. > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* For this reason, it is safe, in this case, to just > > go ahead and > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0* drain the list, without the need of taking the > > budget_lock. > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0*/ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0unpark_parked_vcpus(ops, &sdom->parked_vcpus); >=20 > I think it is safe currently.=C2=A0=C2=A0But is there any reason not to j= ust > grab the lock anyway?=C2=A0=C2=A0We don't expect cap adjustment actions t= o be > that common, and it would mean less chance of error in the future. >=20 The code for doing that properly is a little more involved. That's because unpark_parked_vcpus() takes runqueue locks, and hence can't be called with the budget lock held anyway. We'd therefore need to do the "trick" of the temporary list, as we do already in repl_sdom_budget() and csched2_context_saved(). That's why I did not do that here... but, after all, if I actually do things that way, I can kill the comment, so probably the number of changed lines for this patch would be the same (if not smaller! :-D). I'll think about it (with a bias toward taking the lock, as you suggest). Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-JiO6u9CXXZw2n4oBtcRr 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 iQIcBAABCAAGBQJZVNSmAAoJEBZCeImluHPuOcoQAI/qV/JxszVzXLTCPCstvvTu 0QsoHX5J2ycgFE0GonHlprqR4iCFqkb1x76M/gN0VOxo8rA3Ya3bly9zybcxzvyM 4gXHbVRCO10Bf+/7xYTJ7HvBD8ZUNjhb39mg/DL1sDXbfwFuqdr/Q4qCZ3c61m4b KuxzsG7qGYQOJacLN1WOjL2297syX8MwqUssYhSo8UXKpu1Osm+RIJzMgmEF4omW TFRj+oxZ5o0T9L5WFD0NCNwvvuHV5AwLbanUXJ9CpCqkaU982MKBGvGeMc/2dz9o Dvbd6WiarCQ6KoDAccqVbJEpIwhhKdsp1HVqNhwvRToqBI3mSJwvFN7Vh0A3arPa lDu7rjyVw8bNCtCGWnDiYPjHqbepcLRdkneReG3UiDKK2DC2GDRnwsMSpY72seIS ONLIKIL6EiCw75dq5GkcLrh4kpBEXSSNVDn/GAKCaaEa1gbjo8od7BPqhfBTO7r+ TEjfnJSp6SBE23Gh8xE37ZAuBgNcTICSj263hwkCtC/wnF/eLpS3gmNwJf9RsPEk CVfrmbR/pOtDwyXjZUmNd3r0JH3dWqIhQw55Az6jdOqXC0dhclTelH/56IrGEGw2 EC+VKuODt/fJQK2sKAVgcqFnK0bjG69KdA1dlj/IAWzikfxgc7LkvdpIBB/n9BQE xCyf5sGK7JRPGiG7K5I8 =n7sl -----END PGP SIGNATURE----- --=-JiO6u9CXXZw2n4oBtcRr-- --===============8574559118164891143== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============8574559118164891143==--