Live Migration ToDo

Live Migration ToDo

[Artyom]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

Hello! I would like to see a list of suggestions/ideas/tickets for
improving live migration (especially performance and algorithms). There is
a page https://wiki.qemu.org/ToDo/LiveMigration, but it has not been
updated for a long time. Thanks

[-- Attachment #2: Type: text/html, Size: 336 bytes --]

Re: Live Migration ToDo

[Peter Xu]

Hi,

On Mon, Apr 25, 2022 at 01:41:27PM +0300, Artyom wrote:
> Hello! I would like to see a list of suggestions/ideas/tickets for
> improving live migration (especially performance and algorithms). There is
> a page https://wiki.qemu.org/ToDo/LiveMigration, but it has not been
> updated for a long time. Thanks

Yes I think you're right and it's a good idea we should at some point
revive the page so it always contains up-to-date contents.

Do you mean that you want to contribute to QEMU project by working on some
(obviously, not bit-sized) performance related tasks on live migration to
improve the software?

So far I am aware that Leonardo was working on zero-copy sender side for
it, Juan was experimenting some bitmap split researches, and I'm working on
a bit of the postcopy specific enhancements.  I'm not sure what I can do
here to help you start any form of contribution, maybe starting from
knowing more context of what you want and plan. :)

Thanks,

-- 
Peter Xu

Re: Live Migration ToDo

[Artyom]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

Thank you for your response. Yes, I would like to work on some task, and
eventually I would like to use it as my student project. For example, it
might be possible to implement the technique from the article Post-Copy,
Hines, 2009: demand paging, active push, prepaging and dynamic
self-ballooning. As far as I understood from the postcopy documentation,
the pages are pushed sequentially, but it is possible to implement a new
prepaging strategy. Or are there any obstacles to implementing the ideas of
this paper in QEMU?

On Mon, Apr 25, 2022 at 9:34 PM Peter Xu <peterx@redhat.com> wrote:

> Hi,
>
> On Mon, Apr 25, 2022 at 01:41:27PM +0300, Artyom wrote:
> > Hello! I would like to see a list of suggestions/ideas/tickets for
> > improving live migration (especially performance and algorithms). There
> is
> > a page https://wiki.qemu.org/ToDo/LiveMigration, but it has not been
> > updated for a long time. Thanks
>
> Yes I think you're right and it's a good idea we should at some point
> revive the page so it always contains up-to-date contents.
>
> Do you mean that you want to contribute to QEMU project by working on some
> (obviously, not bit-sized) performance related tasks on live migration to
> improve the software?
>
> So far I am aware that Leonardo was working on zero-copy sender side for
> it, Juan was experimenting some bitmap split researches, and I'm working on
> a bit of the postcopy specific enhancements.  I'm not sure what I can do
> here to help you start any form of contribution, maybe starting from
> knowing more context of what you want and plan. :)
>
> Thanks,
>
> --
> Peter Xu
>
>

[-- Attachment #2: Type: text/html, Size: 2124 bytes --]

Re: Live Migration ToDo

[Peter Xu]

On Tue, Apr 26, 2022 at 01:39:58AM +0300, Artyom wrote:
> Thank you for your response. Yes, I would like to work on some task, and
> eventually I would like to use it as my student project. For example, it
> might be possible to implement the technique from the article Post-Copy,
> Hines, 2009: demand paging, active push, prepaging and dynamic
> self-ballooning. As far as I understood from the postcopy documentation,
> the pages are pushed sequentially, but it is possible to implement a new
> prepaging strategy. Or are there any obstacles to implementing the ideas of
> this paper in QEMU?

I'm a bit confused.  Firstly, Dave implemented postcopy for QEMU years ago,
please see migration/postcopy-ram.c.  Or do you mean you want to implement
some specific optimization for QEMU's postcopy?

Thanks,

-- 
Peter Xu

Re: Live Migration ToDo

[Artyom]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

Yes, the original postcopy paper (
https://kartikgopalan.github.io/publications/hines09postcopy_osr.pdf)
suggests optimizations. For example, prepaging uses hints from the VM's
page access patterns to reduce both the number of major network faults and
the duration of the migration phase. After examining the code in
migration/, I could not find any mention of these optimizations. Perhaps
the ideas from the paper have already been tried to implement in QEMU, but
they were abandoned?

On Tue, Apr 26, 2022 at 1:51 AM Peter Xu <peterx@redhat.com> wrote:

> On Tue, Apr 26, 2022 at 01:39:58AM +0300, Artyom wrote:
> > Thank you for your response. Yes, I would like to work on some task, and
> > eventually I would like to use it as my student project. For example, it
> > might be possible to implement the technique from the article Post-Copy,
> > Hines, 2009: demand paging, active push, prepaging and dynamic
> > self-ballooning. As far as I understood from the postcopy documentation,
> > the pages are pushed sequentially, but it is possible to implement a new
> > prepaging strategy. Or are there any obstacles to implementing the ideas
> of
> > this paper in QEMU?
>
> I'm a bit confused.  Firstly, Dave implemented postcopy for QEMU years ago,
> please see migration/postcopy-ram.c.  Or do you mean you want to implement
> some specific optimization for QEMU's postcopy?
>
> Thanks,
>
> --
> Peter Xu
>
>

[-- Attachment #2: Type: text/html, Size: 1895 bytes --]

Re: Live Migration ToDo

[Peter Xu]

On Tue, Apr 26, 2022 at 02:17:41AM +0300, Artyom wrote:
> Yes, the original postcopy paper (
> https://kartikgopalan.github.io/publications/hines09postcopy_osr.pdf)
> suggests optimizations. For example, prepaging uses hints from the VM's
> page access patterns to reduce both the number of major network faults and
> the duration of the migration phase. After examining the code in
> migration/, I could not find any mention of these optimizations. Perhaps
> the ideas from the paper have already been tried to implement in QEMU, but
> they were abandoned?

They're partly implemented, afaict.

See ram_find_and_save_block(), if we got a postcopy requested page we'll by
default remember it in rs->last_page and we'll do forward-direction-only
bubbling since we'll start to send follow up pages from there.

We also have free page reportings too with virtio-balloon device's
existance.

I don't think we have double-direction bubbling, or multi-pivot bubbling.
I'm not sure whether they were discussed/abandoned or not.  I think Dave
should know the best so I'll leave the rest to him..

-- 
Peter Xu