From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKV4h-0007C2-7o for qemu-devel@nongnu.org; Tue, 05 Jul 2016 14:28:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKV4e-0001Jt-UT for qemu-devel@nongnu.org; Tue, 05 Jul 2016 14:27:58 -0400 References: <1467127721-9564-1-git-send-email-silbe@linux.vnet.ibm.com> <1467127721-9564-2-git-send-email-silbe@linux.vnet.ibm.com> <818452bb-a196-bac8-87a7-e283451a9494@redhat.com> <87a8hxa319.fsf@oc4731375738.ibm.com> <8760skklhh.fsf@oc4731375738.ibm.com> From: Max Reitz Message-ID: <5785923c-48c2-41a7-b1db-ac279abac058@redhat.com> Date: Tue, 5 Jul 2016 20:27:46 +0200 MIME-Version: 1.0 In-Reply-To: <8760skklhh.fsf@oc4731375738.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6xtA5CurcaadK21uUwVtuFh1Jw8CfFSHP" Subject: Re: [Qemu-devel] [PATCH 1/1] Improve block job rate limiting for small bandwidth values List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sascha Silbe , qemu-block@nongnu.org Cc: Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6xtA5CurcaadK21uUwVtuFh1Jw8CfFSHP From: Max Reitz To: Sascha Silbe , qemu-block@nongnu.org Cc: Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org Message-ID: <5785923c-48c2-41a7-b1db-ac279abac058@redhat.com> Subject: Re: [PATCH 1/1] Improve block job rate limiting for small bandwidth values References: <1467127721-9564-1-git-send-email-silbe@linux.vnet.ibm.com> <1467127721-9564-2-git-send-email-silbe@linux.vnet.ibm.com> <818452bb-a196-bac8-87a7-e283451a9494@redhat.com> <87a8hxa319.fsf@oc4731375738.ibm.com> <8760skklhh.fsf@oc4731375738.ibm.com> In-Reply-To: <8760skklhh.fsf@oc4731375738.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05.07.2016 20:06, Sascha Silbe wrote: > Dear Max, >=20 > Max Reitz writes: >=20 >> [ Good signature by key: 0x58B381CE2DC89CF99730EE643BB14202E838ACAD ] >=20 > Feel free to drop by if you happen to be in the Stuttgart area some > time. PGP key signing, a beverage of your choice and optionally some > chatting about qemu and related topics. :) Happens rarely, but does happen. The Red Hat office I'm associated with actually is in Stuttgart, but most of the time I live (and work) 500 km away from it. >> On 04.07.2016 16:30, Sascha Silbe wrote: >>> Max Reitz writes: > [...] > [include/qemu/ratelimit.h] >>>>> static inline int64_t ratelimit_calculate_delay(RateLimit *limit, = uint64_t n) >>>>> { >>>>> int64_t now =3D qemu_clock_get_ns(QEMU_CLOCK_REALTIME); >>>>> + uint64_t delay_slices; >>>>> =20 >>>>> - if (limit->next_slice_time < now) { >>>>> - limit->next_slice_time =3D now + limit->slice_ns; >>>>> + assert(limit->slice_quota && limit->slice_ns); >>>>> + >>>>> + if (limit->slice_end_time < now) { >>>>> + /* Previous, possibly extended, time slice finished; reset= the >>>>> + * accounting. */ >>>>> + limit->slice_start_time =3D now; >>>>> + limit->slice_end_time =3D now + limit->slice_ns; >>>>> limit->dispatched =3D 0; >>>>> } >>>>> - if (limit->dispatched =3D=3D 0 || limit->dispatched + n <=3D l= imit->slice_quota) { >>>>> - limit->dispatched +=3D n; >>>>> + >>>>> + limit->dispatched +=3D n; >>>>> + if (limit->dispatched < limit->slice_quota) { >>>> >>>> Nitpick: This should probably stay <=3D. >>> >>> This is a subtle edge case. Previously, when limit->dispatched =3D=3D= >>> limit->slice_quota, we returned 0 so that the _current_ request (whic= h >>> is still within quota) wouldn't be delayed. Now, we return a delay so= >>> that the _next_ request (which would be over quota) will be delayed. >> >> Hm, but that depends on the size of the next request. Of course, if we= >> get limit->dispatched =3D=3D limit->slice_quota we know for sure that = we >> need to delay the next request. But if we get limit->dispatched =3D=3D= >> limit->slice_quota - 1... Then we probably also have to delay it, but = we >> don't know for sure. >=20 > No matter where exactly we draw the line, due to the way the block job > rate limiting works (fixed size time slices, fixed size requests) there= > will always be cases where we're off the target rate quite a bit, in on= e > or the other direction. >=20 > For rate limits where we can send an integer number of chunks per time > slice (i.e. some MiB/s sized value), the "<" condition is probably > better. We'll send out a couple of chunks that exactly match the quota,= > then sleep for the rest of the time slice. If we'd use "<=3D", we'd sen= d > out one extra chunk before we start sleeping. >=20 > But I don't care much either way, "<=3D" is fine with me, too. Well, and above all, we'll hopefully replace all of this in 2.8 anyway. Max --6xtA5CurcaadK21uUwVtuFh1Jw8CfFSHP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEvBAEBCAAZBQJXe/wjEhxtcmVpdHpAcmVkaGF0LmNvbQAKCRA7sUIC6DisrdKt B/9OShZQGk2/tuT6A9fN/xWFfQIteV7fdIwB3lZrIRWML71FxoAPYL72Yi1xihN3 zRSY8ya8Bm8tZ4ZhCy2jSwIFtEIqJT9vZhn26VtCo+zJsFYQrkQ5SDr3I0vNRgz7 f1BltGjLaPVGwgdit2Up2tgUJtNxorn5J7Z4+mba+ucAHj2S2Pasu55aPTLX3JQf 1kjDoRHxcPh2uivNloyD/uKF0rnmMKFihP2Myddqbj3lVk3d3kibwlDU1EHEYgtY YXQe60W6YvDJNaiLNkagzF2f6BrB8vVrGX9XbF60yq6NS+XGL+BIHO5uLDgC+Qmd fcovr+2/dFsQqk+I+IF/sTAe =4Ll5 -----END PGP SIGNATURE----- --6xtA5CurcaadK21uUwVtuFh1Jw8CfFSHP--