From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Gonglei <arei.gonglei@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Juan Quintela <quintela@redhat.com>,
luonengjun@huawei.com, "pl@kamp.de" <pl@kamp.de>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"owasserm@redhat.com" <owasserm@redhat.com>,
"aliguori@amazon.com" <aliguori@amazon.com>,
"chenliang (T)" <chenliang88@huawei.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/7] migration: Optimization the xbzrle and fix two corruption issues
Date: Fri, 28 Feb 2014 11:39:01 +0000 [thread overview]
Message-ID: <20140228113901.GJ2695@work-vm> (raw)
In-Reply-To: <53106B6E.6050301@huawei.com>
* Gonglei (arei.gonglei@huawei.com) wrote:
> On 2014/2/28 17:19, Dr. David Alan Gilbert wrote:
>
> > * Gonglei (Arei) (arei.gonglei@huawei.com) wrote:
> >
> > Hi,
> >
> >> a. Optimization the xbzrle remarkable decrease the cache misses.
> >> The efficiency of compress increases more than fifty times.
> >> Before the patch set, the cache almost totally miss when the
> >> number of cache item less than the dirty page number. Now the
> >> hot pages in the cache will not be replaced by other pages.
> >
> > Nice, what do you use as your performance test case for xbzrle?
>
>
> The VM we used with 25G memory and 1Gbit nic. We run a test procedure
> in the vm, which as this:
>
> #include <stdio.h>
> #include <stdlib.h>
> #define PAGE_SIZE 4096
> void main(void)
> {
> char *p,*p1;
> long i,j,z;
>
> p = (char*)calloc(8*1024,1024*1024);
> if( p == NULL ){
> printf("fail to calloc \n");
> exit(1);
> }
> for(;;){
> p1 = p;
> for( i = 0 ; i < 8*1024 ; i++ ){
>
> for( j = 0 ; j < 1024*1024 ; j+=PAGE_SIZE ){
> *p1 = 0x55;
> p1+=PAGE_SIZE;
> }
> }
> }
> }
>
> finally,
> the results of without enable xbzrle: 115MB/sec
>
> using xbzrle without optimization (the size of cache 2G): 116MB/sec
>
> using xbzrle with our optimization (the size of cache 2G): 150MB/sec
Hmm yes, it's not a very realistic test is it.
Having said that, I've not managed to find a reallistic test people
can agree on; I was hoping you had one!
You're listing the differences in in MB/sec - what about total
time to migrate?
However, the other question is why your optimisation works well
with that test; is it just the CPU overhead that it's reducing
because it's not bothering to copy lots of stuff into the cache?
If that's all the guest is running, I can't see that it would
actually XBZRLE much - maybe just OS pages.
What do the 'info migrate' stats look like with/without your
optimisation - I'm interested in how many xbzrle pages are sent?
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2014-02-28 11:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 4:05 [Qemu-devel] [PATCH 0/7] migration: Optimization the xbzrle and fix two corruption issues Gonglei (Arei)
2014-02-28 9:19 ` Dr. David Alan Gilbert
2014-02-28 10:56 ` Gonglei
2014-02-28 11:39 ` Dr. David Alan Gilbert [this message]
2014-02-28 13:08 ` 陈梁
2014-02-28 13:08 ` Eric Blake
2014-02-28 13:21 ` 陈梁
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=20140228113901.GJ2695@work-vm \
--to=dgilbert@redhat.com \
--cc=aliguori@amazon.com \
--cc=arei.gonglei@huawei.com \
--cc=chenliang88@huawei.com \
--cc=luonengjun@huawei.com \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pl@kamp.de \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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.