Re: [Qemu-devel] [PATCH 0/7] migration: Optimization the xbzrle and fix two corruption issues

[陈梁]

> * Gonglei (address@hidden) wrote:
>> On 2014/2/28 17:19, Dr. David Alan Gilbert wrote:
>> 
>>> * Gonglei (Arei) (address@hidden) 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 / address@hidden / Manchester, UK

I am in home now, can not do some other tests. BTW, we know 
the limit of migration speed is the bandwidth of nic and the speed
of cpu. The sets of patches just resolve them. When the size of the
cache is small(2GB), the algorithm of the old code will be cache miss
totally, the bandwidth of nic is the limit. If the size of the cache is big
enough(8GB), the result is 2.4GB/sec ,the usage of cpu is 100%. 
After reducing the data copy, the result is 3.1GB/sec.