From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 03/24] xen: credit1: return the 'time remaining to the limit' as next timeslice. Date: Mon, 12 Sep 2016 19:00:58 +0200 Message-ID: <1473699658.6339.26.camel@citrix.com> References: <147145358844.25877.7490417583264534196.stgit@Solace.fritz.box> <147145427423.25877.10573077044748803993.stgit@Solace.fritz.box> <2436cc42-80bc-b51a-8fca-366b3d81537f@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0238614047900527057==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjUbk-00028W-Di for xen-devel@lists.xenproject.org; Mon, 12 Sep 2016 17:01:24 +0000 In-Reply-To: <2436cc42-80bc-b51a-8fca-366b3d81537f@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , xen-devel@lists.xenproject.org Cc: George Dunlap List-Id: xen-devel@lists.xenproject.org --===============0238614047900527057== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-jMfmhTHANn6/RAeO1gTL" --=-jMfmhTHANn6/RAeO1gTL Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-12 at 16:14 +0100, George Dunlap wrote: > On 17/08/16 18:17, Dario Faggioli wrote: > >=20 > > If vcpu x has run for 200us, and sched_ratelimit_us is > > 1000us, continue running x _but_ return 1000us-200us as > > the next time slice. This way, next scheduling point will > > happen in 800us, i.e., exactly at the point when x crosses > > the threshold, and can be descheduled (if appropriate). > >=20 > > Right now (without this patch), we're always returning > > sched_ratelimit_us (1000us, in the example above), which > > means we're (potentially) allowing x to run more than > > it should have been able to (even when considering rate > > limiting into account). > Part of the reason I went with this in the first place was because I > wanted to avoid really short timers.=C2=A0=C2=A0Part of the reason for th= e > ratelimit was actually to limit the amount of time spent in the > scheduler.=C2=A0=C2=A0Since we expect ratelimit to normally be pretty sho= rt, > waiting for the whole ratelimit time seemed like a good idea. >=20 I see what you mean. I personally am not a fan of ratelimit, because of how it acts behind the algorithm's back and mess with and partly invalidates the algorithms own assumptions and properties (not that these assumptions and properties are very clear in Credit1, even before ratelimiting, but, anyway :-)), and this is an example of that. Nevertheless, I see that this patch may, up to some extent, re- introduce some of the "small timers" that it was ratelemiting's own purpose to mitigate. So, I guess, either we make this a three way condition, introducing an absolute minimum runtime value, under which we don't ever want to go, e.g.: =C2=A0tsclice =3D MICROSECS(prv->runtime_us) - runtime > CSCHED_MIN_TIMER : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MICROSECS(prv->runtime_us) - runti= me : CSCHED_MIN_TIMER; or we leave things as they are now. The MIN_TIMER option would let at least the cases where the vcpu has run for a few, but not too much, time to be more precisely scheduled. E.g., if ratelimit_us is 1000us, MIN_TIMER is 500us, and the vcpu run for 400us, we let it be preempted after 600us more (i.e., 1000us in total =3D=3D ratelimit_us), instead of after 1000us more (i.e., 1400us in total). I also agree on the fact that most of the times ratelimit_us and MIN_TIMER will be close enough (like in the example above) that it won't probably matter much... but if someone set ratelimit_us to something higher (say, 10ms --we accept values as big as the timeslice, which is 30ms b default) it may matter a bit. What do you think? If we decide not to care, and leave things as they are, I'd add a comment saying that code is like that on purpose, so we won't trip over this again in 1 or 2 years. :-) Regards, Dario --=C2=A0 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-jMfmhTHANn6/RAeO1gTL 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 iQIcBAABCAAGBQJX1t9KAAoJEBZCeImluHPuYZAQAOasWjI4FNywJp1mrVHBMlWb YA+HYBsFF09kHxCWu2VsKsFwOcYLHWzGCQSpfN/9DB73nRtGYH6UJwle9Kxlp6ke DjzBV0k8KSYmipwXfGSMx4/jZ0C40FSFLjgsr1Aourwu+nZwmXvUUMGhCB8WauKk xCcDKD+k9MHtpFf2IVmusNebTxTh9yYipnFooGRmACV27ZPz1LgG/J9kJ/McOaxL mJQG1xvtAUN87hBFeIPDz2c62zFTxHM0u7DoOYbXEJPqTyFZEbraz7Bzkety9h98 kF+0zlrBxqYAlY7oMGgGRctgVVUPhPdiUPHG45PO0UljzI/Y0simJP5IQ3+yZcU7 PFByz+PamZlBAc8W+q5ke9Y8aUYjbgs6yO8X10yUXdaZeDzYRbUY+40/lr/5PRl8 4JgkQ+k2bV3rsC2wsuR8ejgX4s59+2Fb0K9r4nE/cBA8VWW1VoRIFrncoTj/EV67 n+n1qGSbEknOLcctgvXqsHijXcWE3K+PUEnXItV11dDHyDwqQB5vLJB6Dy5j1+Qs fSZ7P7X18GPnfO0jiObXbje8xV0o5v0Jc2Ioi1YTqij9Qba5lFzuhqSplsc86QMe R9uKkNboGVmUgm0nWGZfqLpSadkD3Gjgcv5FN2xbpBLAtaNYxMYrrxStrlwR6/OM Eeo1RPcaDczm1ofaF8jw =gjGI -----END PGP SIGNATURE----- --=-jMfmhTHANn6/RAeO1gTL-- --===============0238614047900527057== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0238614047900527057==--