From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDYws-0001XZ-HU for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDYwn-0001Us-Vo for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:29 -0500 Received: from [199.232.76.173] (port=36848 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDYwn-0001Up-Pe for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:25 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:45565) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDYwm-0002OJ-Ph for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:25 -0500 Message-ID: <4B0E30A5.9060200@web.de> Date: Thu, 26 Nov 2009 08:39:17 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1257169258297-git-send-email-lirans@il.ibm.com> <4B0C647D.6090709@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCAD66771F3869A8AF1FF8EA4" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 2/3 v5] Block live migration List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liran Schour Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCAD66771F3869A8AF1FF8EA4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Liran Schour wrote: > jan.kiszka@web.de wrote on 25/11/2009 00:55:57: >=20 >=20 >> trying to understand the code and fixing some cosmetic issues around >> progress reporting, one potentially performance-relevant question popp= ed > up: >> lirans@il.ibm.com wrote: >>> diff --git a/block-migration.c b/block-migration.c >>> new file mode 100644 >>> index 0000000..4b4eddf >>> --- /dev/null >>> +++ b/block-migration.c >> ... >> >>> +static int mig_read_device_bulk(QEMUFile *f, BlkMigDevState *bms) >>> +{ >>> + int nr_sectors; >>> + int64_t total_sectors, cur_sector =3D 0; >>> + BlockDriverState *bs =3D bms->bs; >>> + BlkMigBlock *blk; >>> + >>> + blk =3D qemu_malloc(sizeof(BlkMigBlock)); >>> + blk->buf =3D qemu_malloc(BLOCK_SIZE); >>> + >>> + cur_sector =3D bms->cur_sector; >>> + total_sectors =3D bdrv_getlength(bs) >> SECTOR_BITS; >> Why re-calculating total_sectors here? Specifically bdrv_getlength() c= an >> be a non-trivial I/O operation. >> >> And what is the difference to bms->total_sectors which looks a lot > like... >> [...] >>> + >>> +static void init_blk_migration(QEMUFile *f) >>> +{ >>> + BlkMigDevState **pbmds, *bmds; >>> + BlockDriverState *bs; >>> + >>> + for (bs =3D bdrv_first; bs !=3D NULL; bs =3D bs->next) { >>> + if(bs->type =3D=3D BDRV_TYPE_HD) { >>> + bmds =3D qemu_mallocz(sizeof(BlkMigDevState)); >>> + bmds->bs =3D bs; >>> + bmds->bulk_completed =3D 0; >>> + bmds->total_sectors =3D bdrv_getlength(bs) >> SECTOR_BIT= S; >> ...it already contains all the information we need? >> >=20 > You are right no need to figure it out once again. We can use the old > total_sectors value. Perfect. Meanwhile I've quite a few patches here, including that change, will hopefully manage to send them out today. Jan --------------enigCAD66771F3869A8AF1FF8EA4 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.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAksOMKgACgkQitSsb3rl5xSQVQCeL01DiPYKrNEGLZ88u40khZsM UcAAn0JE0hd+dvaV53DQKxojLkOukCL4 =Iaim -----END PGP SIGNATURE----- --------------enigCAD66771F3869A8AF1FF8EA4--