[Top][All Lists]

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

Re: [Qemu-devel] vm state save/restore question

From: Alexander Graf
Subject: Re: [Qemu-devel] vm state save/restore question
Date: Tue, 19 Jun 2012 23:00:16 +0200

On 19.06.2012, at 22:30, Benjamin Herrenschmidt wrote:

> On Tue, 2012-06-19 at 16:59 +0200, Juan Quintela wrote:
>>>> - The hash table (mentioned above). This is just a big chunk of
>> memory
>>>> (it will routinely be 16M), so I really don't want to start
>> iterating
>>>> all elements, just a bulk load will do, and the size might actually
>> be
>>>> variable.
>> This is going to kill migration download time.  With current setup, we
>> just sent something like 1-2MB in stage 3 (i.e. after the machine is
>> down).  Default downtime is 30ms, And 16MB is going to take around 1s
>> on gigabit ethenet.
>> Once said that, if you told me the state that you want to sent, I can
>> take a look.
> Well, we don't have much of a choice unless we do something really fancy
> but that would be a second step...
> The MMU hash table on power is where all our translations go. What we
> could do is put in some knowledge about what translations are actually
> necessary for the guest and which ones can be rebuild (faulted in),
> essentially by adding knowledge to qemu/kvm about the "bolted" bit that
> the guests uses for translations that must not be evicted.
> However, that would require at least some interaction between the guest
> and qemu/kvm to enable the function since this bit is a guest SW
> construct (unless it got architected in recent PAPR, I need to dbl
> check).

How is the problem different from RAM? It's a 16MB region that can be accessed 
by the guest even during transfer time, so it can get dirty during the 
migration. But we only need to really transfer the last small delta at the end 
of the migration, right?


reply via email to

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