[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 0/9] KVM: Dirty ring support (QEMU part)
From: |
Peter Xu |
Subject: |
Re: [PATCH RFC 0/9] KVM: Dirty ring support (QEMU part) |
Date: |
Tue, 3 Mar 2020 12:32:24 -0500 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH RFC 0/9] KVM: Dirty ring support (QEMU part),
Peter Xu <=