From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ8Kz-0007mO-Nk for qemu-devel@nongnu.org; Fri, 22 Mar 2013 16:13:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJ8Ky-0003wV-61 for qemu-devel@nongnu.org; Fri, 22 Mar 2013 16:13:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJ8Kx-0003wJ-Uh for qemu-devel@nongnu.org; Fri, 22 Mar 2013 16:13:16 -0400 Message-ID: <514CBB54.2060703@redhat.com> Date: Fri, 22 Mar 2013 14:13:08 -0600 From: Eric Blake MIME-Version: 1.0 References: <1363956370-23681-1-git-send-email-pl@kamp.de> <1363956370-23681-8-git-send-email-pl@kamp.de> In-Reply-To: <1363956370-23681-8-git-send-email-pl@kamp.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2WDBGFSDDEHNKMSLRHPEB" Subject: Re: [Qemu-devel] [PATCHv4 7/9] migration: do not sent zero pages in bulk stage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: quintela@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Luiz Capitulino , Orit Wasserman , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2WDBGFSDDEHNKMSLRHPEB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/22/2013 06:46 AM, Peter Lieven wrote: > during bulk stage of ram migration if a page is a > zero page do not send it at all. > the memory at the destination reads as zero anyway. >=20 > even if there is an madvise with QEMU_MADV_DONTNEED > at the target upon receipt of a zero page I have observed > that the target starts swapping if the memory is overcommitted. > it seems that the pages are dropped asynchronously. Your commit message fails to mention that you are updating QMP to record a new stat, although I agree with what you've done. If you do respin, make mention of this fact in the commit message. >=20 > Signed-off-by: Peter Lieven > --- > arch_init.c | 24 ++++++++++++++++++++---- > hmp.c | 2 ++ > include/migration/migration.h | 2 ++ > migration.c | 3 ++- > qapi-schema.json | 6 ++++-- > qmp-commands.hx | 3 ++- > 6 files changed, 32 insertions(+), 8 deletions(-) >=20 > +++ b/qapi-schema.json > @@ -496,7 +496,9 @@ > # > # @total: total amount of bytes involved in the migration process > # > -# @duplicate: number of duplicate pages (since 1.2) > +# @duplicate: number of duplicate (zero) pages (since 1.2) > +# > +# @skipped: number of skipped zero pages (since 1.5) > # > # @normal : number of normal pages (since 1.2) > # > @@ -510,7 +512,7 @@ > { 'type': 'MigrationStats', > 'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' , > 'duplicate': 'int', 'normal': 'int', 'normal-bytes': 'int',= > - 'dirty-pages-rate' : 'int' } } > + 'dirty-pages-rate' : 'int', 'skipped': 'int' } } Your layout here doesn't match the order that you documented things in. But it is a dictionary of name-value pairs, so order is not significant to the interface. About the only thing the order might affect is whether the rest of your code, which assigns fields in documentation order, is slightly less efficient because it is jumping around the C struct rather than hitting it in linear order, but that would be in the noise on a benchmark. So I won't insist on a respin. However, since you are touching QMP, it wouldn't hurt to have Luiz chime in. I'm okay if this goes in as-is. Or, if you do spin a v5 for other reasons, then lay out MigrationStats in documentation order, and improve the commit message. If those are the only changes you make, then you can keep: Reviewed-by: Eric Blake --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2WDBGFSDDEHNKMSLRHPEB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRTLtVAAoJEKeha0olJ0Nq0rcH/3OkC3jDNsAcbomo+QS7onOe p3FfmHPKYSaDc6uNkPCSYV2LAa3w7ECvt8l6GT3kRKMfpxWcxGIAb0PlGIpLwEOx bUXqsIxDvg5eyByuuwQd/GOphfIC3hZnFVC7/6+b/w/cDEq2XFedXoT5sUKPjiol UHVkK/amrvndlZR3bGmJmV6ZOLO2Iz1Nhi9v5K9/Wemx16msAVWKWGTlb3akALq0 d16GUz6EImT5EWn7BBkwd23xl5X34AjcemImcq84jxt3sSHuhuAX7urydNP0kLuX yvjyPCkgB/XC9XpMouTz1zuqEAl6HQP+FBkkbYnDhVPaUoZ3O+ATsWMaRfjplUE= =Us2l -----END PGP SIGNATURE----- ------enig2WDBGFSDDEHNKMSLRHPEB--