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

[Peter Lieven]

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?

>> 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.

> 
> 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.

Peter

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