On Wed, Feb 05, 2020 at 09:17:40AM -0500, Peter Xu wrote: > This is still RFC because the kernel counterpart is still under > review. However please feel free to read into the code a bit if you > want; they've even got rich comments so not really in WIP status > itself. Any kind of comments are greatly welcomed. > > For anyone who wants to try (we need to upgrade kernel too): > > KVM branch: > https://github.com/xzpeter/linux/tree/kvm-dirty-ring > > QEMU branch for testing: > https://github.com/xzpeter/qemu/tree/kvm-dirty-ring > > Overview > ======== > > KVM dirty ring is a new interface to pass over dirty bits from kernel > to the userspace. Instead of using a bitmap for each memory region, > the dirty ring contains an array of dirtied GPAs to fetch, one ring > per vcpu. > > There're a few major changes comparing to how the old dirty logging > interface would work: > > - Granularity of dirty bits > > KVM dirty ring interface does not offer memory region level > granularity to collect dirty bits (i.e., per KVM memory > slot). Instead the dirty bit is collected globally for all the vcpus > at once. The major effect is on VGA part because VGA dirty tracking > is enabled as long as the device is created, also it was in memory > region granularity. Now that operation will be amplified to a VM > sync. Maybe there's smarter way to do the same thing in VGA with > the new interface, but so far I don't see it affects much at least > on regular VMs. > > - Collection of dirty bits > > The old dirty logging interface collects KVM dirty bits when > synchronizing dirty bits. KVM dirty ring interface instead used a > standalone thread to do that. So when the other thread (e.g., the > migration thread) wants to synchronize the dirty bits, it simply > kick the thread and wait until it flushes all the dirty bits to the > ramblock dirty bitmap. > > A new parameter "dirty-ring-size" is added to "-accel kvm". By > default, dirty ring is still disabled (size==0). To enable it, we > need to be with: > > -accel kvm,dirty-ring-size=65536 > > This establishes a 64K dirty ring buffer per vcpu. Then if we > migrate, it'll switch to dirty ring.
Ping? I'd like to know whether there's any high level comment about all these... Considering that the kernel counterpart is still during review, I guess we don't need to spend much time on that much, assuming it'll be a ring of dirty addresses. The rest should be irrelevant to kernel so I'd glad to know if there's comments on those parts. Thanks, -- Peter Xu
