* Wei Wang (wei.w.w...@intel.com) wrote:
> On 02/09/2018 04:15 AM, Dr. David Alan Gilbert wrote:
> > * Wei Wang (wei.w.w...@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.
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK