From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4428-0006zq-TA for qemu-devel@nongnu.org; Mon, 07 Jul 2014 04:12:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X4421-00070p-DF for qemu-devel@nongnu.org; Mon, 07 Jul 2014 04:12:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4421-00070f-4m for qemu-devel@nongnu.org; Mon, 07 Jul 2014 04:12:13 -0400 Date: Mon, 7 Jul 2014 10:12:07 +0200 From: Stefan Hajnoczi Message-ID: <20140707081207.GA21110@stefanha-thinkpad.redhat.com> References: <1404464167-5188-1-git-send-email-stefanha@redhat.com> <1404464167-5188-3-git-send-email-stefanha@redhat.com> <8738eh30gg.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <8738eh30gg.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v2 2/2] block: bump coroutine pool size for drives List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Paolo Bonzini , ming.lei@canonical.com, qemu-devel@nongnu.org --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 04, 2014 at 12:03:27PM +0200, Markus Armbruster wrote: > Stefan Hajnoczi writes: > > @@ -2112,6 +2115,7 @@ void bdrv_detach_dev(BlockDriverState *bs, void *= dev) > > bs->dev_ops =3D NULL; > > bs->dev_opaque =3D NULL; > > bs->guest_block_size =3D 512; > > + qemu_coroutine_adjust_pool_size(-64); > > } > > =20 > > /* TODO change to return DeviceState * when all users are qdevified */ >=20 > This enlarges the pool regardless of how the device model uses the block > layer. Isn't this a bit crude? >=20 > Have you considered adapting the number of coroutines to actual demand? > Within reasonable limits, of course. I picked the simplest algorithm because I couldn't think of one which is clearly better. We cannot predict future coroutine usage so any algorithm will have pathological cases. In this case we might as well stick to the simplest implementation. Stefan --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTulZXAAoJEJykq7OBq3PI8CoIAJlvn44QvOxTCVPvcCvqr5wW ZXfJU/pGA2n66wKdtrRdUIXoWpPo0RHnnPewYYROVY5VNf/zuIOwqk1eStWo1g24 Qpw3Ayyz/hluvLkv+tSYlwdnY3/BRlWvF5A71uNia8TZK2EUP9s3F9TDfeAMrbHL R3ws85LdJ4/Vr5G8gg5FBiIdbAb1GWMRu08dEBC/mN3KUpZG0XToU72FgTB39cdc TGLlgdfA5V7CW5mvcU0g9Jl3BozqbhFvcqaRIlZoLW8K3kZlHgPetWlkkv3beH0n bwFLJCT+XalrbotunSeIhM6XItNaGMZ6tRqAaCcReoWHZfAI3JYnhBzUnuVCTdQ= =qezK -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--