Re: [Qemu-devel] [PATCH v2 0/3] virtio-balloon: free page hint reporting support

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Wei Wang (wei.w.wang@intel.com) wrote:
> On 02/09/2018 04:15 AM, Dr. David Alan Gilbert wrote:
> > * Wei Wang (wei.w.wang@intel.com) wrote:
> > > This is the deivce part implementation to add a new feature,
> > > VIRTIO_BALLOON_F_FREE_PAGE_HINT to the virtio-balloon device. The device
> > > receives the guest free page hints from the driver and clears the
> > > corresponding bits in the dirty bitmap, so that those free pages are
> > > not transferred by the migration thread to the destination.
> > > 
> > > Please see the driver patch link for test results:
> > > https://lkml.org/lkml/2018/2/4/60
> > Hi Wei,
> >     I'll look at the code a bit more - but first some more basic
> > questions on that lkml post:
> > 
> >      a) The idle guest time thing is a nice result; can you just state
> >         what the host was, speed of connection, and what other options
> >         you were using?
> > 
> >      b) The workload test, the one with the kernel compile; you list
> >         the kernel compile time but don't mention any changes in the
> >         migration times of the ping-pong; can you give those times as
> >         well?
> > 
> >      c) What's your real workload that this is aimed at?
> >         Is it really for people migrating idle VMs - or do you have some
> >         NFV application in mind, if so why not include a figure for
> >         those?
> > 
> 
> Hi Dave,
> 
> Thanks for joining the review. Please see below info.
> 
> a) Environment info
>     - Host:
>         - Physical CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
>         - kernel: 3.10.0
> 
>     - Guest:
>         - kernel: 4.15.0
>         - QEMU setup: -cpu host -M pc -smp 4,threads=1,sockets=1 -m 8G
> --mem-prealloc -realtime mlock=on -balloon virtio,free-page-hint=true
> 
>     - Migration setup:
>         - migrate_set_speed 0
>         - migrate_set_downtime 0.01  (10ms)

That's an unusually low downtime (and I'm not sure what setting the
speed to 0 does!).

> b) Michael asked the same question on the kernel patches, I'll reply there
> with you cc-ed, so that kernel maintainers can also see it. Btw, do you have
> any other workloads you would suggest to have a try?

No, not really; I guess it's best for VMs that are either idle or have
lots of spare RAM.

> c) This feature is requested by many customers (e.g. general cloud vendors).
> It's for general use cases. As long as the guest has free memory, it will
> benefit from this optimization when doing migration. It's not specific for
> NFV usages, but for sure NFV will also benefit from this feature if we think
> about service chaining, where multiple VMs need to co-work with each other.
> In that case, migrating one VM will just break the working model, which
> means we will need to migrate all the VMs. A shorter migration time will be
> very helpful.

I thought of NFV because their VMs tend to have lots of extra RAM but
most seems unused most of the time.

Dave

> 
> Best,
> Wei
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK