From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zguhz-0004Mt-8T for qemu-devel@nongnu.org; Tue, 29 Sep 2015 09:12:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zguht-00026u-CX for qemu-devel@nongnu.org; Tue, 29 Sep 2015 09:12:39 -0400 Date: Tue, 29 Sep 2015 15:12:23 +0200 From: Kevin Wolf Message-ID: <20150929131223.GI3930@noname.str.redhat.com> References: <1442589793-7105-1-git-send-email-mreitz@redhat.com> <1442589793-7105-18-git-send-email-mreitz@redhat.com> <20150922141701.GD3999@noname.str.redhat.com> <56016CF5.8030709@redhat.com> <560A844C.6020801@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sXc4Kmr5FA7axrvy" Content-Disposition: inline In-Reply-To: <560A844C.6020801@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 17/38] block: Add BlockBackendRootState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Alberto Garcia , qemu-block@nongnu.org, Markus Armbruster , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz , John Snow --sXc4Kmr5FA7axrvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 29.09.2015 um 14:30 hat Eric Blake geschrieben: > On 09/29/2015 05:17 AM, Alberto Garcia wrote: > > On Tue 22 Sep 2015 05:00:05 PM CEST, Max Reitz wrote: > >=20 > >>> The correct way to solve this seems to be that each BB has its own > >>> I/O throttling filter. Actually, if we could lift the throttling code > >>> to BlockBackend, that might solve the problem. > >> > >> So yes, as long as we have throttling on the BDS level, something may > >> always break when having multiple BBs per BDS, because you'd probably > >> want throttling to be on the BB level. But lifting that doesn't seem a > >> trivial task, and I don't really know whether I want this in this > >> series. > >> > >> Especially considering that right now you cannot have multiple BBs per > >> BDS. > >> > >> All in all: Yes, before we allow multiple BBs per BDS we want > >> throttling to be on the BB level. But this is nothing that should be > >> done in or for this series, since right now we do not allow multiple > >> BBs per BDS. > >=20 > > I agree that it makes sense to move throttling to the BB level. It's > > probably not trivial but I don't think it's too complex either. I can > > give it a look once this series has been merged. >=20 > Ultimately, I think we want throttling at both levels. I can make the > argument that in a cloud, a guest should not be able to consume more > than X resources (throttling at the BB, regardless of what BDS tree it > is associated with); but I can also argue that I may want to throttle > specific BDS (a backing chain with network backing file and local active > file: throttle the backing file to limit network traffic, and the guest > gets faster as it moves more local; or conversely, a common backing file > and one-off guest: throttle the active layer to do performance analysis > of the bottlenecks where the guest differs from the common backing layer). Yes, but the throttling that we currently have is the one that belongs into BlockBackend. This becomes very clear when you consider that the throttling moves to the new top when you create live snapshots. Throttling for individual BDSes should be done by a filter block driver. In fact, I also suspect that the BB-level filtering should eventually be done by a filter block driver, but that's something for which we don't have a clear design yet. Kevin --sXc4Kmr5FA7axrvy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWCo42AAoJEH8JsnLIjy/WF+cQAIry4zBDHnfb9ohe6NITxeHQ fF2D6KeLo597eBSjP9b4RGGpnz7H+GM7jjmrz0p1fgSCWHDeCNKyu1LERRh5MWUH hSl7sU7J2Ru//cFpYwoOMUb/O9hXJFPOlfmGPGY2B7fSZUQaSZmA3r6qn3TgBF80 QZSmJ8NC/b26J/VT/gZW5YcGBilwVC8omgtNWfqUxbctnCJV/FOWR1c0/uHdc2cx Yz9v2Jg70qgH7sCPE/8+Db6JGRcsNgwdH8h+xYJPWI6SZmQ0VxlH7VXAQ5A0YgYy bweBjR6Kjo4rGhhWTT8kJC+ViPmv00JRYt4lE3inl2IPqeKmaGz+u15yhDL226HL 86Fjr7zOGOPWOwqgbmS7/ptSBn0V2m4Vf4uAHXgy94XtXChkNiG1GWP3dI4huLy1 1DUW/xXKETU7y3YejOS2Ikzw+s+n7jIfVuEY/ENLy7W7+9UiFntOl/mXTS17vpx/ RbA0FdYOTDSfDf0Q7QfcN8onrvxqEUZ1tXWCVzh8nUtTDH57HBn5WR5o1bm/2yc2 lrZIK4YboqwQI8C1+87uQLZ6uY+WXvYya8DyZn8BL7+51TsCz+1JtmtXYsI0ziDd s0vyvTFjo5eHMne8t0G+TsWW1wzptCNfmHoGSym484uh8qIpVCzlzmrW4v2tMRDs pumQ0UvQ+HSUvWx57ADt =BgYT -----END PGP SIGNATURE----- --sXc4Kmr5FA7axrvy--