qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] RFC migration of zero pages
Date: Thu, 31 Jan 2013 16:06:29 +0200


On Jan 31, 2013 4:03 PM, "Peter Lieven" <address@hidden> wrote:
>
>
> Am 31.01.2013 um 14:59 schrieb Avi Kivity <address@hidden>:
>
>>
>> On Jan 31, 2013 12:29 PM, "Orit Wasserman" <address@hidden> wrote:
>> >
>> > On 01/31/2013 11:48 AM, Gleb Natapov wrote:
>> > > On Thu, Jan 31, 2013 at 09:47:24AM +0200, Orit Wasserman wrote:
>> > >> 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.
>> > >>
>> > > What is wrong with mincore()?
>> >
>> > Avi/Michael do you remember why mincore can't be used to check if a guest page is unmapped?
>>
>> A page may be not in core, but also nonzero (for example swap).
>
> What about hugetables? Afaik, there are not swappable - at least they where somewhen in the past.
> Maybe it would be possible to have a performance improvement if they are used.
>

Nobody uses them, now that transparent huge pages are available.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]