similar to: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

> > > > * Liang Li (liang.z.li at intel.com) wrote: > > > The current QEMU live migration implementation mark the all the > > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > > will be processed and that takes quit a lot of CPU cycles. > > > > > > From guest's point of view, it doesn't care about the

> > > > * Liang Li (liang.z.li at intel.com) wrote: > > > The current QEMU live migration implementation mark the all the > > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > > will be processed and that takes quit a lot of CPU cycles. > > > > > > From guest's point of view, it doesn't care about the

> > > * Liang Li (liang.z.li at intel.com) wrote: > > > > The current QEMU live migration implementation mark the all the > > > > guest's RAM pages as dirtied in the ram bulk stage, all these > > > > pages will be processed and that takes quit a lot of CPU cycles. > > > > > > > > From guest's point of view, it doesn't

> > No. And it's exactly what I mean. The ballooned memory is still > > processed during live migration without skipping. The live migration code is > in migration/ram.c. > > So if guest acknowledged VIRTIO_BALLOON_F_MUST_TELL_HOST, we can > teach qemu to skip these pages. > Want to write a patch to do this? > Yes, we really can teach qemu to skip these pages

> > No. And it's exactly what I mean. The ballooned memory is still > > processed during live migration without skipping. The live migration code is > in migration/ram.c. > > So if guest acknowledged VIRTIO_BALLOON_F_MUST_TELL_HOST, we can > teach qemu to skip these pages. > Want to write a patch to do this? > Yes, we really can teach qemu to skip these pages

The current QEMU live migration implementation mark the all the guest's RAM pages as dirtied in the ram bulk stage, all these pages will be processed and that takes quit a lot of CPU cycles. >From guest's point of view, it doesn't care about the content in free pages. We can make use of this fact and skip processing the free pages in the ram bulk stage, it can save a lot CPU cycles

The current QEMU live migration implementation mark the all the guest's RAM pages as dirtied in the ram bulk stage, all these pages will be processed and that takes quit a lot of CPU cycles. >From guest's point of view, it doesn't care about the content in free pages. We can make use of this fact and skip processing the free pages in the ram bulk stage, it can save a lot CPU cycles

> Subject: Re: [RFC qemu 0/4] A PV solution for live migration optimization > > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's

> Subject: Re: [RFC qemu 0/4] A PV solution for live migration optimization > > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's

On Thu, Mar 03, 2016 at 05:46:15PM +0000, Dr. David Alan Gilbert wrote: > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's point of view,

On Thu, Mar 03, 2016 at 05:46:15PM +0000, Dr. David Alan Gilbert wrote: > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's point of view,

> > > > > > Only detect the unmapped/zero mapped pages is not enough. > > > Consider > > > > > the > > > > > > situation like case 2, it can't achieve the same result. > > > > > > > > > > Your case 2 doesn't exist in the real world. If people could > > > > > stop their main memory

> > > > > > Only detect the unmapped/zero mapped pages is not enough. > > > Consider > > > > > the > > > > > > situation like case 2, it can't achieve the same result. > > > > > > > > > > Your case 2 doesn't exist in the real world. If people could > > > > > stop their main memory

On Fri, Mar 04, 2016 at 08:23:09AM +0000, Li, Liang Z wrote: > > On Thu, Mar 03, 2016 at 05:46:15PM +0000, Dr. David Alan Gilbert wrote: > > > * Liang Li (liang.z.li at intel.com) wrote: > > > > The current QEMU live migration implementation mark the all the > > > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > > >

On Fri, Mar 04, 2016 at 08:23:09AM +0000, Li, Liang Z wrote: > > On Thu, Mar 03, 2016 at 05:46:15PM +0000, Dr. David Alan Gilbert wrote: > > > * Liang Li (liang.z.li at intel.com) wrote: > > > > The current QEMU live migration implementation mark the all the > > > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > > >

On Mon, Mar 07, 2016 at 01:40:06PM +0200, Michael S. Tsirkin wrote: > On Mon, Mar 07, 2016 at 06:49:19AM +0000, Li, Liang Z wrote: > > > > No. And it's exactly what I mean. The ballooned memory is still > > > > processed during live migration without skipping. The live migration code is > > > in migration/ram.c. > > > > > > So if guest

On Mon, Mar 07, 2016 at 01:40:06PM +0200, Michael S. Tsirkin wrote: > On Mon, Mar 07, 2016 at 06:49:19AM +0000, Li, Liang Z wrote: > > > > No. And it's exactly what I mean. The ballooned memory is still > > > > processed during live migration without skipping. The live migration code is > > > in migration/ram.c. > > > > > > So if guest

On Wed, Mar 09, 2016 at 03:27:54PM +0000, Li, Liang Z wrote: > > On Mon, Mar 07, 2016 at 01:40:06PM +0200, Michael S. Tsirkin wrote: > > > On Mon, Mar 07, 2016 at 06:49:19AM +0000, Li, Liang Z wrote: > > > > > > No. And it's exactly what I mean. The ballooned memory is still > > > > > > processed during live migration without skipping. The

On Wed, Mar 09, 2016 at 03:27:54PM +0000, Li, Liang Z wrote: > > On Mon, Mar 07, 2016 at 01:40:06PM +0200, Michael S. Tsirkin wrote: > > > On Mon, Mar 07, 2016 at 06:49:19AM +0000, Li, Liang Z wrote: > > > > > > No. And it's exactly what I mean. The ballooned memory is still > > > > > > processed during live migration without skipping. The

> * Roman Kagan (rkagan at virtuozzo.com) wrote: > > On Fri, Mar 04, 2016 at 08:23:09AM +0000, Li, Liang Z wrote: > > > > On Thu, Mar 03, 2016 at 05:46:15PM +0000, Dr. David Alan Gilbert wrote: > > > > > * Liang Li (liang.z.li at intel.com) wrote: > > > > > > The current QEMU live migration implementation mark the all > > > > >