From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQj1u-0005Ln-Nr for qemu-devel@nongnu.org; Thu, 20 Mar 2014 15:53:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQj1k-00051o-PV for qemu-devel@nongnu.org; Thu, 20 Mar 2014 15:53:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQj1k-00051k-Gy for qemu-devel@nongnu.org; Thu, 20 Mar 2014 15:53:20 -0400 Message-ID: <532B472B.2020704@redhat.com> Date: Thu, 20 Mar 2014 13:53:15 -0600 From: Eric Blake MIME-Version: 1.0 References: <1395145464-5524-1-git-send-email-arei.gonglei@huawei.com> <1395145464-5524-11-git-send-email-arei.gonglei@huawei.com> In-Reply-To: <1395145464-5524-11-git-send-email-arei.gonglei@huawei.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HVcltsnw1KFljWFb0qBLPLNNL2t1KUh8f" Subject: Re: [Qemu-devel] [PATCH v3 10/10] XBZRLE: update the doc of XBZRLE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: arei.gonglei@huawei.com, qemu-devel@nongnu.org Cc: ChenLiang , owasserm@redhat.com, pbonzini@redhat.com, weidong.huang@huawei.com, quintela@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HVcltsnw1KFljWFb0qBLPLNNL2t1KUh8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/18/2014 06:24 AM, arei.gonglei@huawei.com wrote: > From: ChenLiang >=20 > update the doc of XBZRLE Having the subject line and the body of the commit message be identical is redundant. And just by looking at the commit message, I can't see WHY you are updating things. If you were to keep this as a separate commit, I'd suggest it look more like: XBZRLE: document cache miss policy Add a section to the XBZRLE documentation describing how the page cache determines which pages are hot. That said, I think you should squash this documentation update into patch 5/10 where you actually implement it, so that a single patch becomes self-documenting why you went with this design. At which point, the combined patch commit message should look something like: XBZRLE: optimize XBZRLE to decrease cache misses =2E..existing text from 5/10... Additionally, document the new cache age policy. >=20 > Signed-off-by: ChenLiang > Signed-off-by: Gonglei > --- > docs/xbzrle.txt | 7 +++++++ > 1 file changed, 7 insertions(+) >=20 > diff --git a/docs/xbzrle.txt b/docs/xbzrle.txt > index cc3a26a..cdf1e3e 100644 > --- a/docs/xbzrle.txt > +++ b/docs/xbzrle.txt > @@ -71,6 +71,13 @@ encoded buffer: > encoded length 24 > e9 07 0f 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 03 01 67 01 01 6= 9 > =20 > +The strategy of updating cache > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Copy-and-paste from bad examples already in this file, but it's nicer when the length of =3D=3D=3D=3D matches the heading it is paired with. > +Keeping the hot page in cache is effective to decrease cache missing. > +XBZRLE use a counter as the age of page. The counter will increase > +after the ram dirty bitmap syncing. When cache conflicts XBZRLE only > +replace the old page in cache. Suggestions for better grammar: Cache update strategy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Keeping the hot pages in the cache is effective for decreased cache misses. XBZRLE uses a counter as the age of each page. The counter will increase after each ram dirty bitmap sync. When a cache conflict is detected, XBZRLE will only evict pages in the cache that are older than a threshold. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --HVcltsnw1KFljWFb0qBLPLNNL2t1KUh8f 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTK0crAAoJEKeha0olJ0NqLhoH/0sQ3SWPARkNKVWG+lNLeN4i s8LAyD5Kcoj4eZyHiBAh/N+okfK/jAoXLjWkh7nDExQhCml6bgLWriU9s1eApVjc V0bA5GvA8oDOBFHSn36HVYxbt/XVUDZ4xpPRkhiUMo1oRivH4M9i0NPczLvTeApY tF7cZe7sxqhctSB2eTomQu6VgbKUfOB6VLFhJaMFncr/GM4rrnuTSD75nMGaHqtY 2QHYHXKku6e1Gn1QfnBgPdrCxj1N1EXeokz2YIZyLnjrw7t87YmBAv3XC/xffmhE GG9nkOgu5OwN53bIct0A26Z6CylE3D8yxEyLQzLqXzPbpOuYnQ4vDTyx3dviR8A= =uvPn -----END PGP SIGNATURE----- --HVcltsnw1KFljWFb0qBLPLNNL2t1KUh8f--