Message ID | 20210108164601.406146-1-peterx@redhat.com |
---|---|
Headers | show |
Series | KVM: Dirty ring support (QEMU part) | expand |
On Fri, Jan 08, 2021 at 11:45:48AM -0500, Peter Xu wrote: > This is v4 of the qemu dirty ring interface support. > > It is merely the same as v3 content-wise, but there're a few things to mention > besides the rebase itself: > > - I picked up two patches from Eric Farman for the linux-header updates (from > Eric's v3 series) for convenience just in case any of the series would got > queued by any maintainer. > > - One more patch is added as "KVM: Disable manual dirty log when dirty ring > enabled". I found this when testing the branch after rebasing to latest > qemu, that not only the manual dirty log capability is not needed for kvm > dirty ring, but more importantly INITIALLY_ALL_SET is totally against kvm > dirty ring and it could silently crash the guest after migration. For this > new commit, I touched up "KVM: Add dirty-gfn-count property" a bit. > > - A few more documentation lines in qemu-options.hx. > > - I removed the RFC tag after kernel series got merged. > > Again, this is only the 1st step to support dirty ring. Ideally dirty ring > should grant QEMU the possibility to remove the whole layered dirty bitmap so > that dirty ring will work similarly as auto-converge enabled but should better; > we will just throttle vcpus with the dirty ring kvm exit rather than explicitly > adding a timer to stop the vcpu thread from entering the guest again (like what > we did with current migration auto-converge). Some more information could also > be found in the kvm forum 2020 talk regarding kvm dirty ring (slides 21/22 [1]). > > That next step (to remove all the dirty bitmaps, as mentioned above) is still > discussable: firstly I don't know whether there's anything I've overlooked in > there. Meanwhile that's also only services huge VM cases, may not be extremely > helpful with a lot major scenarios where VMs are not that huge. > > There's probably other ways to fix huge VM migration issues, majorly focusing > on responsiveness and convergence. For example, Google has proposed some new > userfaultfd kernel capability called "minor modes" [2] to track page minor > faults and that could be finally served for that purpose too using postcopy. > That's another long story so I'll stop here, but just as a marker along with > the dirty ring series so there'll still be a record to reference. > > Said that, I still think this series is very worth merging even if we don't > persue the next steps yet, since dirty ring is disabled by default, and we can > always work upon this series. > > Please review, thanks. Ping - Paolo, what would be your take on this series? Thanks,