From: ChenLiang <chenliang88@huawei.com>
To: Amit Shah <amit.shah@redhat.com>
Cc: weidong.huang@huawei.com, quintela@redhat.com,
qemu-devel@nongnu.org, dgilbert@redhat.com,
arei.gonglei@huawei.com, pbonzini@redhat.com,
peter.huangpeng@huawei.com
Subject: Re: [Qemu-devel] [PATCH RESEND for 2.3 4/6] xbzrle: check 8 bytes at a time after an concurrency scene
Date: Wed, 10 Dec 2014 11:55:49 +0800 [thread overview]
Message-ID: <5487C445.9030506@huawei.com> (raw)
In-Reply-To: <20141210031810.GC27208@grmbl.mre>
On 2014/12/10 11:18, Amit Shah wrote:
> On (Mon) 24 Nov 2014 [19:55:50], arei.gonglei@huawei.com wrote:
>> From: ChenLiang <chenliang88@huawei.com>
>>
>> The logic of old code is correct. But Checking byte by byte will
>> consume time after an concurrency scene.
>>
>> Signed-off-by: ChenLiang <chenliang88@huawei.com>
>> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>> ---
>> xbzrle.c | 28 ++++++++++++++++++----------
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/xbzrle.c b/xbzrle.c
>> index d27a140..0477367 100644
>> --- a/xbzrle.c
>> +++ b/xbzrle.c
>> @@ -50,16 +50,24 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t *new_buf, int slen,
>>
>> /* word at a time for speed */
>> if (!res) {
>> - while (i < slen &&
>> - (*(long *)(old_buf + i)) == (*(long *)(new_buf + i))) {
>> - i += sizeof(long);
>> - zrun_len += sizeof(long);
>> - }
>> -
>> - /* go over the rest */
>> - while (i < slen && old_buf[i] == new_buf[i]) {
>> - zrun_len++;
>> - i++;
>> + while (i < slen) {
>> + if ((*(long *)(old_buf + i)) == (*(long *)(new_buf + i))) {
>> + i += sizeof(long);
>> + zrun_len += sizeof(long);
>> + } else {
>> + /* go over the rest */
>> + for (j = 0; j < sizeof(long); j++) {
>> + if (old_buf[i] == new_buf[i]) {
>> + i++;
>> + zrun_len++;
>
> I don't see how this is different from the code it's replacing. The
> check and increments are all the same. Difficult to see why there'll
> be a speed benefit. Can you please explain? Do you have any
> performance numbers for before/after?
>
> Thanks,
>
> Amit
>
> .
>
Hi Amit:
+ for (j = 0; j < sizeof(long); j++) {
+ if (old_buf[i] == new_buf[i]) {
+ i++;
+ zrun_len++;
+ } else {
+ break;
+ }
+ }
+ if (j != sizeof(long)) {
+ break;
+ }
The branch of *j != sizeof(long)* may not be hit after an concurrency scene.
so we can continue doing "(*(long *)(old_buf + i)) == (*(long *)(new_buf + i))".
On the another side the old code does "old_buf[i] == new_buf[i]".
To be honest, This scene is rare.
Best regards
ChenLiang
next prev parent reply other threads:[~2014-12-10 3:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 11:55 [Qemu-devel] [PATCH RESEND for 2.3 0/6] xbzrle: optimize the xbzrle arei.gonglei
2014-11-24 11:55 ` [Qemu-devel] [PATCH RESEND for 2.3 1/6] xbzrle: optimize XBZRLE to decrease the cache misses arei.gonglei
2014-11-24 11:55 ` [Qemu-devel] [PATCH RESEND for 2.3 2/6] xbzrle: rebuild the cache_is_cached function arei.gonglei
2014-11-24 11:55 ` [Qemu-devel] [PATCH RESEND for 2.3 3/6] xbzrle: don't check the value in the vm ram repeatedly arei.gonglei
2014-11-24 11:55 ` [Qemu-devel] [PATCH RESEND for 2.3 4/6] xbzrle: check 8 bytes at a time after an concurrency scene arei.gonglei
2014-12-10 3:18 ` Amit Shah
2014-12-10 3:55 ` ChenLiang [this message]
2014-12-10 10:02 ` Amit Shah
2014-12-10 10:37 ` Dr. David Alan Gilbert
2014-12-10 10:05 ` Juan Quintela
2014-12-10 10:41 ` Dr. David Alan Gilbert
2014-11-24 11:55 ` [Qemu-devel] [PATCH RESEND for 2.3 5/6] migration: optimize xbzrle by reducing data copy arei.gonglei
2014-12-10 10:35 ` Juan Quintela
2014-12-10 10:39 ` Dr. David Alan Gilbert
2014-12-11 2:34 ` ChenLiang
2014-12-11 8:57 ` Dr. David Alan Gilbert
2014-11-24 11:55 ` [Qemu-devel] [PATCH RESEND for 2.3 6/6] migration: clear the dead code arei.gonglei
2014-12-10 2:33 ` [Qemu-devel] [PATCH RESEND for 2.3 0/6] xbzrle: optimize the xbzrle Amit Shah
2014-12-10 10:09 ` Amit Shah
2014-12-11 2:24 ` ChenLiang
2014-12-16 15:01 ` Dr. David Alan Gilbert
2014-12-22 13:00 ` ChenLiang
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=5487C445.9030506@huawei.com \
--to=chenliang88@huawei.com \
--cc=amit.shah@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.huangpeng@huawei.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.