Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size

Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size

[Kevin Wolf]

Am 01.03.2013 um 03:35 hat Wenchao Xia geschrieben:
> 于 2013-2-28 18:50, Kevin Wolf 写道:
> >Am 28.02.2013 um 09:09 hat Wenchao Xia geschrieben:
> >>This version have following limitation:
> >>   1 in patch 3 only dirty page got written, clean page is not touched, so
> >>it will have trouble when savevm to an old internal snapshot, which
> >>will be fixed later if this approach seems OK.
> >
> >Basically you need a bdrv_zero_vmstate(), right? I think this would
>   Yes, an API to initialize the data at the beginning, or just write 4K
> zero in the progress....
> 
> >actually be a bug fix, because snapshots might today get references to
> >unused VM state clusters that are just leftovers from the last snapshot.
> >
>   In a qcow2 file that have snapA, if user type "savevm snapA", then
> qemu will delete old snapA and then create new snapA.
>   Do you mean that new snapA and old snapA may use the same cluster
> that is not cleaned up as zeros? I guess this brings no trouble to old
> stream savevm, but will brings trouble to plane savevm in this patch.
> If so, I think yes this bug fix can solve the problem.

The scenario I'm thinking of is something like:

1. (qemu) savevm A
2. (qemu) quit
3. qemu-img snapshot -c B test.qcow2
4. qemu-img snapshot -d A test.qcow2

Step 1 creates a snapshot from a running VM, so it writes a lot of VM
state data to the image. Step 3 creates another snapshot, however
outside of a running qemu, so without VM state. It wrongly gets a
reference to all VM state clusters of A, which haven't been overwritten
or discarded since snapshot A was taken. When deleting A in step 4, the
clusters cannot be freed because they are still referenced by B (which
doesn't need them at all)

Kevin

Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size

[Wenchao Xia]

>> You probably get some improvements of the file size when the migration
>> takes a while, depending on how much of the memory actually has to be
>> saved. You might however end up with a lot more small writes instead of
>> some big ones before, which might hurt performance.
>>
>> Do you have any data about the resulting performance and file size?
>>
>    ah, an important issue I haven't test, thanks for tipping it, let
> me add code for migration to file, and have a test. It also
> can be optimized a bit in qemu_fseek(), but IMHO the optimization
> for small writes would better goto block layer either in qemu
> or underling components in system.
>
Hi,Juan
  talking about performance, in migration there are two buffer used,
one in qemu_file as static array, and one in migration as dynamic 
allocated buffer,
should they be merged to avoid extra memcpy?

Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size

[Pavel Hrdina]

On 03/04/2013 04:04 PM, Wenchao Xia wrote:
>
>>> You probably get some improvements of the file size when the migration
>>> takes a while, depending on how much of the memory actually has to be
>>> saved. You might however end up with a lot more small writes instead of
>>> some big ones before, which might hurt performance.
>>>
>>> Do you have any data about the resulting performance and file size?
>>>
>>    ah, an important issue I haven't test, thanks for tipping it, let
>> me add code for migration to file, and have a test. It also
>> can be optimized a bit in qemu_fseek(), but IMHO the optimization
>> for small writes would better goto block layer either in qemu
>> or underling components in system.
>>
> Hi,Juan
>   talking about performance, in migration there are two buffer used,
> one in qemu_file as static array, and one in migration as dynamic
> allocated buffer,
> should they be merged to avoid extra memcpy?
>

Hi Wenchao,

This is already posted on qemu-devel list,

http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg04119.html
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg04222.html

Pavel

Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size

[Wenchao Xia]

于 2013-3-5 20:04, Pavel Hrdina 写道:
> On 03/04/2013 04:04 PM, Wenchao Xia wrote:
>>
>>>> You probably get some improvements of the file size when the migration
>>>> takes a while, depending on how much of the memory actually has to be
>>>> saved. You might however end up with a lot more small writes instead of
>>>> some big ones before, which might hurt performance.
>>>>
>>>> Do you have any data about the resulting performance and file size?
>>>>
>>>    ah, an important issue I haven't test, thanks for tipping it, let
>>> me add code for migration to file, and have a test. It also
>>> can be optimized a bit in qemu_fseek(), but IMHO the optimization
>>> for small writes would better goto block layer either in qemu
>>> or underling components in system.
>>>
>> Hi,Juan
>>   talking about performance, in migration there are two buffer used,
>> one in qemu_file as static array, and one in migration as dynamic
>> allocated buffer,
>> should they be merged to avoid extra memcpy?
>>
>
> Hi Wenchao,
>
> This is already posted on qemu-devel list,
>
> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg04119.html
> http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg04222.html
>
> Pavel
>
   Great, hope this can be upstream fast, thanks for tipping it.

-- 
Best Regards

Wenchao Xia