* 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. Dave > > Best, > Wei > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK