[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC migration of zero pages
From: |
Orit Wasserman |
Subject: |
Re: [Qemu-devel] RFC migration of zero pages |
Date: |
Thu, 31 Jan 2013 09:47:24 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
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).
> 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.
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.
Regards,
Orit
>
> Peter
>
>
Re: [Qemu-devel] RFC migration of zero pages, Gleb Natapov, 2013/01/31
Re: [Qemu-devel] RFC migration of zero pages, Gleb Natapov, 2013/01/31
Re: [Qemu-devel] RFC migration of zero pages, Avi Kivity, 2013/01/31