From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 1/4] xen: credit2: implement utilization cap Date: Tue, 25 Jul 2017 19:29:15 +0200 Message-ID: <1501003755.26429.11.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> <1498730994.7288.13.camel@citrix.com> <3515a3e9-d81f-e3f3-9d1a-1936a761fe66@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3681719307453550600==" 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 1da3ed-0001Z2-Fu for xen-devel@lists.xenproject.org; Tue, 25 Jul 2017 17:29:55 +0000 In-Reply-To: <3515a3e9-d81f-e3f3-9d1a-1936a761fe66@citrix.com> 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 --===============3681719307453550600== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-GP+/wPB798KYCdknSuxk" --=-GP+/wPB798KYCdknSuxk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-07-25 at 15:34 +0100, George Dunlap wrote: > On 06/29/2017 11:09 AM, Dario Faggioli wrote: > > 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". >=20 > Sorry, dropped this thread to prepare for XenSummit. >=20 NP. > Well I think there's a principle a bit like Ockham's Razor: In > general, > if there's not an obvious advantage between two implementations, the > simpler / easier to understand implementation is better. >=20 > My sense is also that in general, as long as context switching > overhead > doesn't become an issue, allowing a guest to run for shorter bursts > more > often is better than allowing it to run for longer bursts less > often.=C2=A0=C2=A0A > cpu-bound task will perform about as well in both cases, but a > latency-sensitive task will perform much worse if it's allowed to > burn > up its timeslice and forced to wait for a big chunk of time. >=20 That's actually a fair point. > On the other hand, my intuitions about how to improve AFL fuzzing > these > last few weeks have turned out to be consistently wrong, so at the > moment I'm not inclined to be overly confident in my intuition > without > some testing. :-) >=20 Well, this is a similar situation to the one in the other thread. It's an edge case that, likely, will never or only very rarely occur. So, we don't need to think too much about it, and we well even afford to follow your intuition! :-D Mmm... Maybe this came out a bit less of a "cheering you up", as I wanted it to be, but hey, I tried! :-P :-P :-P No, jokes apart, I like your argument about the effect this may have on latency sensitive workload, if they happen to suffer from one of this overrun, so I will change the code the way 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) --=-GP+/wPB798KYCdknSuxk 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 iQIcBAABCAAGBQJZd3/sAAoJEBZCeImluHPux8YQAKT2n5Avbsruhc/s2eJITbTF 7yW9FYClFz/MAWpvgzTdtYE97mnhIIPujQD+Q+bsqoK26KiBfN6oSHahX3ISQ+AJ 1lBXp7iYqYrKrcrR51dScPVINUF6KyjltH4He3FYx1oTVdIEkTZU2TU9QU2sPtT9 UW+QzaVRghJ0nKL1JPWcOu24r5YmYN9+tbelNAeCEH1QDwImTm7g5Y6hJByV6NYn FC+YHD72GAf3nNlKWKTiomkgIsD/0AIS3jNE3yXbrCqtf2rxHlsNFjoYIH3zpX6M cDsIw+otpXh7skpoB/riAMxTGrsB2NwfUMY9R3IKxq8quTQvvpiq1bVNBju2HOwx NM+VkZe+15LAsOQ63miINCozwEsJEaykoKlmjIXjFqg1vKECW918ZJ2Kxg1z0dNB C5zQg8AgWjgvHQbwXKziT2WZPK69KGOZdsAO2tdcK3tPD+r64fJpJb3H5rXKNOgS fOuUC4wSDOnWkoMO9Cd7uu8YKSR3oVOYDAKWkhilOXB6f88AUIaAxvpT426x/fw3 Ctqv7fpqXao55hJrdPXGYWay6OJpMgi0WriFPBO6QrKsndjWm83jgYfHghiT4WDW bC5aWHkBiseB7vbuTmO4YpgxuSfO6wsTLY0+qpeUWYMd4bC4U5xYM67TnQ/sM6aj pVLSmE5d7kNhx6ojnGqL =/vRk -----END PGP SIGNATURE----- --=-GP+/wPB798KYCdknSuxk-- --===============3681719307453550600== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3681719307453550600==--