From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8LK4-0006Do-TO for qemu-devel@nongnu.org; Thu, 15 Mar 2012 20:47:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8LK3-0000NZ-2P for qemu-devel@nongnu.org; Thu, 15 Mar 2012 20:47:12 -0400 Received: from spam1.wiktel.com ([69.89.207.151]:33896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8LK2-0000MQ-SO for qemu-devel@nongnu.org; Thu, 15 Mar 2012 20:47:10 -0400 From: Richard Laager In-Reply-To: <4F61B817.2010702@redhat.com> References: <1331226917-6658-1-git-send-email-pbonzini@redhat.com> <1331226917-6658-7-git-send-email-pbonzini@redhat.com> <4F5A31B2.3050701@redhat.com> <4F5A46A1.4000508@redhat.com> <1331402560.8577.46.camel@watermelon.coderich.net> <4F5DEBCE.3040409@redhat.com> <1331665990.24052.42.camel@watermelon.coderich.net> <4F604B98.9090606@redhat.com> <1331772155.24052.849.camel@watermelon.coderich.net> <4F61B817.2010702@redhat.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4SmkjeS2gS2lW+RuwGP5" Date: Thu, 15 Mar 2012 19:47:04 -0500 Message-ID: <1331858824.3076.20.camel@watermelon.coderich.net> Mime-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH 06/17] block: use bdrv_{co, aio}_discard for write_zeroes operations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org --=-4SmkjeS2gS2lW+RuwGP5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-03-15 at 10:36 +0100, Paolo Bonzini wrote: > Changing across guest boots is a minor problem, but changing across > migration must be avoided at all costs. >=20 > BTW, after this discussion I think we can instead report > discard_granularity =3D 512 and discard_zeroes_data=3D0 and get most of t= he > benefit, at least on file-backed storage. Are you going to report that to guests all the time, or only when the host supports discard? If you don't report it all the time, you could still be "changing across migration". If you do report it all the time, then you're incurring a performance penalty on systems that don't support discard, as the guest will be sending discard requests that QEMU has to throw away (but by which time some work has been wasted). And either way, what you're proposing means that users with discard_zeros_data =3D 1 hosts can't get the (albeit small) benefits of that because some other QEMU user might want to do a migration across heterogeneous storage. The more I think about this, the more it seems like we just need to make this configurable. Then people that, because of migration concerns, want to advertise lowest-common-denominator storage to their guests can do so (just like they already can and likely do advertise a lowest-common-denominator CPU). Everyone else can get whatever their host supports (just like they do with CPUs). Adding configuration options also means that developers can use QEMU to test guest discard support in various ways. Finally, I see your proposal of advertising fixed discard support to guests (regardless of which set of values is chosen) out of line with the existing QEMU precedent with CPUs as well as the design decision used for discard in the Linux kernel (which passes the values all the way up the stack). While this doesn't inherently mean it's a bad design, I think QEMU should tread carefully. --=20 Richard --=-4SmkjeS2gS2lW+RuwGP5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk9ijYIACgkQbfU6uV4fG87fMwCggcgIx16nMU38MlTr5OZDWwjl zhEAoM9utFlz4vfwYEpKS1L3B/FPSJIJ =l5LX -----END PGP SIGNATURE----- --=-4SmkjeS2gS2lW+RuwGP5--