Re: [Qemu-devel] RFC migration of zero pages

[Orit Wasserman]

On 01/31/2013 10:10 AM, Peter Lieven wrote:
> 
> Am 31.01.2013 um 08:47 schrieb Orit Wasserman <address@hidden>:
> 
>> On 01/31/2013 08:57 AM, Peter Lieven wrote:
>>> Hi,
>>>
>>> I just came across an idea and would like to have feedback if it makes 
>>> sence or not.
>>>
>>> If a VM is started without preallocated memory all memory that has not been 
>>> written to
>>> reads as zeros, right?
>> Hi,
>> No the memory will be unmapped (we allocate on demand).
> 
> Yes, but those unmapped pages will read as zeroes if the guest accesses it?
yes.
> 
>>> If a VM with a lot of unwritten memory is migrated or if the memory 
>>> contains a lot
>>> of zeroed out memory (e.g. Windows or Linux guest with page sanitization) 
>>> all this memory
>>> is allocated on the target during live migration. Especially with KSM this 
>>> leads
>>> to the problem that this memory is allocated and might be not available 
>>> completely as
>>> merging of the pages will happen async.
>>>
>>> Wouldn't it make sense to not send zero pages in the first round where the 
>>> complete
>>> ram is sent (if it is detectable that we are in this stage)?
>> We send one byte per zero page at the moment (see is_dup_page) we can 
>> further optimizing it
>> by not sending it.
>> I have to point out that this is a very idle guest and we need to work on a 
>> loaded guest 
>> which is the more hard problem in migration.
> 
> I was not talking about saving one byte (+ 8 bytes for header), my concern 
> was that we memset all (dup) pages
> including the special case of a zero dup page on the migration target. This 
> allocates the memory or does it not?
> 

> If my above assumption that the guest reads unmapped memory as zeroes is 
> right, this mapping
> is not necessary in the case of a zero dup page.
> 
> We just have to make sure that we are still in the very first round when 
> deciding not to sent
> a zero page, because otherwise it could be a page that has become zero during 
> migration and
> this of course has to be transferred.

OK, so if we won't send the pages than it won't be allocate in the dst and it 
can improve both 
memory usage and reduce cpu consumption on it.
That can be good for over commit scenario.
> 
>>
>> Also I notice that the bottle neck in migrating unmapped pages is the 
>> detection of those pages
>> because we map the pages in order to check them, for a large guest this is 
>> very expensive as mapping a page
>> results in a page fault in the host.
>> So what will be very helpful is actually locating those pages without 
>> mapping them
>> which looks very complicated.
> 
> This would be a nice improvement, but as you said a guest will sooner or 
> later allocate
> all memory if it is not totally idle. However, bigger parts of this memory 
> might have been reset to zeroes.
> This happens on page deallocation in a Windows Guest by default and can also 
> be enforced in LInux
> with page sanitization.

true, but it those cases we will want to zero the page in the dst as this is 
done for security reasons

Orit
> 
> Peter
> 
>>
>> Regards,
>> Orit
>>>
>>> Peter
>>>
>>>
>>
>