From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 1/4] xen: credit2: implement utilization cap Date: Thu, 29 Jun 2017 12:09:54 +0200 Message-ID: <1498730994.7288.13.camel@citrix.com> References: <149692186557.9605.11625777539060264052.stgit@Solace.fritz.box> <149692372627.9605.8252407697848997058.stgit@Solace.fritz.box> <2db5b8c2-eb6b-3926-806e-9bcf2e46b4a1@citrix.com> <1498234767.7405.46.camel@citrix.com> <1498661812.7288.8.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0318704194012069557==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQWPB-0004zQ-5V for xen-devel@lists.xenproject.org; Thu, 29 Jun 2017 10:10:33 +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: Wei Liu , Andrew Cooper , Anshul Makkar , Ian Jackson , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org --===============0318704194012069557== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-+XuT52sFR7GUSFyzYxmA" --=-+XuT52sFR7GUSFyzYxmA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-06-28 at 20:05 +0100, George Dunlap wrote: > On Wed, Jun 28, 2017 at 3:56 PM, Dario Faggioli > wrote: > >=20 > > In the case you describe, at 2T, with budget -C, the first round of > > the > > loop will make the budget 0, and set the next replenishment to 3T. > > As > > you say, since budget is 0, and 0 is <=3D than 0, we stay in the loop > > for > > another round, which sets the budget to C, and the next > > replenishment > > to 4T. >=20 > Ah, right -- I did notice that next_repl was being moved forward each > iteration too, but didn't connect that it would mean you'd end up > going for 2T without calling repl_sdom_budget() again. >=20 > So I'm convinced that this behavior won't break the credit system, > but > I'm not sure why it's an advantage over just having the domain "sit > out" this time period. >=20 I think they're just two different possible implementations, and it's hard to tell, in general, which one is better and which one is worse Depending on very specific characteristics of the workload, in combination with what actually caused the specific occurrence of such a big overrun, and maybe even other factors, either one may behave better or worse. E.g., if the vcpu is "greedy", and always tries to run, as soon as it has some budget, the difference between the two solution is _where_ we put the "sitting period". > Did you actually see this happen in practice on a regular basis > during > your tests, or is this mostly a hypothetical situation we're talking > about here? >=20 It's a safety catch. It really should not happen except from bugs or unless something is really wrong (e.g., in HW). It may happen more regularly if the user manages to set a budget that is really small, compared to the actual resolution of the budget enforcing logic (which is whatever time granularity we use for timers, in that specific host). There are measures already in place to try to prevent that to happen, but I probably can add some more... including a WARN() in this very case. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-+XuT52sFR7GUSFyzYxmA 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 iQIcBAABCAAGBQJZVNHzAAoJEBZCeImluHPuE8IP/iXwELo1VkJi0Rj5mcPK3LKt 34f0ttRMcJZhsC4ueNu1BxmQrHvaHa85lXHyk0KLhAwwKbZm9risD/kB1f4S/8wI FBQlLlcXhKWKt0uI4rZi20t2I1JAb66lr4kNXERGZsU2fEb1nUQFOw5IQBAThVA/ 2Htx8xjUME5zR8jvqV+ry1HAg0Xa3EKzTC2EdwWfPREChkicpgiXZgtoPvcmEsRo BXqMUptiuYExshZ/MPY5dwoj4wK5+BIadqyLnCH2vPtdOoPFTF8T1wF9HcGtXOsK 71hVl/lN7BDYYkflL+VTtPTSBb916/4hDkyQWb3ogoNENWfnLMgrcBCMH/z8Q/cm aJahma0zy0Eiy8UJvecDCkHtJQ1Dj92uBVPMcefmzadph7FlZ6JISP9HoDW/Sa0q zkz9fgMk3Jm6YQT8oV9Gb7Z4m/b3irzavmPHq9AiXjvFg+qhvh29648v0sbxlqhv dsFnryBkrgV7GFkYIJatZPMYRKTwNM8JjlVCedS4wDcraxueDSteOIAbt70uOlqq 3+ImTOPHYm3UEkZrSXY4bQk3pj2tfsv3IV40XH1yQF1voL3ppvlo24mrw9ynfmQu c5xrSMCjdtMFcjANQxXRC1dXu7tnp6/Xqo9M334MxmGFPDT5GrOSWLOL8r5oCRqC /6ZcPDXq4JeCVJlYer7U =V8yk -----END PGP SIGNATURE----- --=-+XuT52sFR7GUSFyzYxmA-- --===============0318704194012069557== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0318704194012069557==--