Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size
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
于 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
Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size
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
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
Am 28.02.2013 um 09:09 hat Wenchao Xia geschrieben: This patch added a new way to savevm: save vmstate as plane contents instead of stream. So the idea is that when we introduce internal live snapshots, you don't keep old state in the saved VM state, but you just overwrite it, right? Or actually, the same works (could work?) for migration to file as well. 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? 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 actually be a bug fix, because snapshots might today get references to unused VM state clusters that are just leftovers from the last snapshot. 2 in patch 3 it saves contents according to address regardless about zero pages, so the size of savevm grows. In my test 128MB guest took about 21M internal snapshot before, and always took 137MB in this way. Although it have above issue, but I'd like to sent the RFC first to see if this is a good way. Next steps will be make savevm lively, save vmstate to image files. About issue 2, it will be OK if we save vmstate to external image files, such as a qcow2 file, which may handle the duplicated zeros(I guess so). in internal snapshot case, the qcow2 internal snapshot need to enhanced to allow store zeros with little space. Yes, we can use the qcow2 zero flag for this. It works on a qcow2 cluster granularity (i.e. 64k by default), which I hope should be sufficient. Kevin
Re: [Qemu-devel] [RFC PATCH 0/4] savevm: save vmsate with fixed size
于 2013-2-28 18:50, Kevin Wolf 写道: Am 28.02.2013 um 09:09 hat Wenchao Xia geschrieben: This patch added a new way to savevm: save vmstate as plane contents instead of stream. So the idea is that when we introduce internal live snapshots, you don't keep old state in the saved VM state, but you just overwrite it, right? Or actually, the same works (could work?) for migration to file as well. exactly, it will overwrite the contents when a page became dirty again, so the vmstate size would not grow unlimited. It works for migration to file as well with a modification to migrate code. 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. 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. 2 in patch 3 it saves contents according to address regardless about zero pages, so the size of savevm grows. In my test 128MB guest took about 21M internal snapshot before, and always took 137MB in this way. Although it have above issue, but I'd like to sent the RFC first to see if this is a good way. Next steps will be make savevm lively, save vmstate to image files. About issue 2, it will be OK if we save vmstate to external image files, such as a qcow2 file, which may handle the duplicated zeros(I guess so). in internal snapshot case, the qcow2 internal snapshot need to enhanced to allow store zeros with little space. Yes, we can use the qcow2 zero flag for this. It works on a qcow2 cluster granularity (i.e. 64k by default), which I hope should be sufficient. Kevin -- Best Regards Wenchao Xia
