From: Eric Blake <eblake@redhat.com>
To: 陈梁 <chenliang0016@icloud.com>
Cc: ChenLiang <chenliang88@huawei.com>,
weidong.huang@huawei.com, quintela@redhat.com,
qemu-devel@nongnu.org, dgilbert@redhat.com, owasserm@redhat.com,
arei.gonglei@huawei.com, mrhines@us.ibm.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH] xbzrle: don't check the value in the vm ram repeatedly
Date: Sat, 29 Mar 2014 08:26:06 -0600 [thread overview]
Message-ID: <5336D7FE.5050904@redhat.com> (raw)
In-Reply-To: <118C69AB-F17E-41B6-AFEF-5C1C02E345C9@icloud.com>
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]
On 03/29/2014 08:15 AM, 陈梁 wrote:
>>
>> Insufficient. Observe what we did at line 52 when looking for the zero-run:
>>
>>>> /* word at a time for speed */
>>>> if (!res) {
>>>> while (i < slen &&
>>>> (*(long *)(old_buf + i)) == (*(long *)(new_buf + i))) {
>>
>> This dereferences 8 bytes at new_buf[i] (on a 64-bit machine)...
>>
>>>> i += sizeof(long);
>>>> zrun_len += sizeof(long);
>>>> }
>>>>
>>>> /* go over the rest */
>>>> while (i < slen && old_buf[i] == new_buf[i]) {
>>
>> ...and this also dereferences those same bytes. But your argument is
>> that new_buf[i] is volatile.
>>
>> You MUST read new_buf[i] into a temporary variable, and if the first
>> read found a difference, then the "go over the rest" analysis must be on
>> that temporary, rather than going back to reading directly from new_buf.
>>
> It is ok, we just need to guarantee that the pages in cache are same to the page in dest side.
> Don‘t care about whether they are same to src side. Because the modified pages during this
> time will be sent at next time.
No, it is not okay - if you are reading the same bytes from new_buf, and
new_buf is volatile, then you MUST read each byte of new_buf exactly
once. Consider this sequence:
old_buf contains
00 00 00 00 00 00 00 00
new_buf initially contains
00 00 00 00 00 00 00 01
so the zrun detection spots that the two buffers are different on the
8-byte read. But then another thread modifies new_buf to be all zeros.
Now the "go over the rest" loop does 8 reads, expecting to find a
difference, but it can't find one.
You really need to do the "go over the rest" loop on an 8-byte temporary
variable. Ever since your patch made new_buf be a volatile buffer,
rather than a static copy, you MUST visit each byte of new_buf exactly once.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-03-29 14:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-29 7:52 [Qemu-devel] [PATCH] xbzrle: don't check the value in the vm ram repeatedly arei.gonglei
2014-03-29 13:53 ` Eric Blake
2014-03-29 14:15 ` 陈梁
2014-03-29 14:26 ` Eric Blake [this message]
[not found] ` <C734EB68-7CC7-4028-BD08-0FC54819FD21@icloud.com>
[not found] ` <F822EA2B-2483-446F-A92C-662B381D1B81@icloud.com>
2014-03-29 15:33 ` Eric Blake
[not found] ` <F5241465-1514-4695-8EE0-F781549403FF@icloud.com>
2014-03-29 15:38 ` Eric Blake
2014-03-31 9:40 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5336D7FE.5050904@redhat.com \
--to=eblake@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=chenliang0016@icloud.com \
--cc=chenliang88@huawei.com \
--cc=dgilbert@redhat.com \
--cc=mrhines@us.ibm.com \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=weidong.huang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).