Re: [Qemu-devel] [PATCH v2 4/6] XBZRLE cache size should not be larger than guest memory size

[Orit Wasserman <owasserm@redhat.com>]

On 01/30/2014 08:48 PM, Dr. David Alan Gilbert wrote:
> * Orit Wasserman (owasserm@redhat.com) wrote:
>> On 01/30/2014 08:23 PM, Dr. David Alan Gilbert wrote:
>>> * Orit Wasserman (owasserm@redhat.com) wrote:
>>>> Signed-off-by: Orit Wasserman <owasserm@redhat.com>
>>>> ---
>>>>   migration.c | 7 +++++++
>>>>   1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/migration.c b/migration.c
>>>> index 46a7305..25add6f 100644
>>>> --- a/migration.c
>>>> +++ b/migration.c
>>>> @@ -479,6 +479,13 @@ void qmp_migrate_set_cache_size(int64_t value, Error **errp)
>>>>           return;
>>>>       }
>>>>
>>>> +    /* Cache should not be larger than guest ram size */
>>>
>>> Why? (It's admittedly odd, but does it actually break something if it's larger?)
>>>
>>
>> Because how XBZRLE works, the idea is that for workload that changes the same pages
>> frequently, we can reduce the amount of transferred data sent by sending only the diff.
>> We also compress the diff itself.
>>
>> The cache is used to store the previous page so we can calculate the diff, so at most it will
>> contain all the guest pages.
>
> It's a hash based cache though isn't it - so there will be some contention for
> a cache size==ram size case?
>

not really because the hash function is so simple it becomes like an index into array.


> Also this does mean that you have to be a little careful to pick a sane XBZRLE cache
> size, since one that's too large will now fail; I can only see that being
> a problem on a machine with a mix of huge and tiny VMs.
>

Yes if you pick the cache too small than you will have lots of missing and the compression
wont be useful. if you pick too large than you wasted memory for nothing.
What also problematic is picking the right workload, it will only be effective if between each
migration iteration the same pages are changed.

> ( I sent the reviewd-by tag separately.)

Thanks,
Orit
>
> Dave
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>