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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.