All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH RFC 0/9] KVM: Dirty ring support (QEMU part)
Date: Tue, 3 Mar 2020 12:32:24 -0500	[thread overview]
Message-ID: <20200303173224.GD464129@xz-x1> (raw)
In-Reply-To: <20200205141749.378044-1-peterx@redhat.com>

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



      parent reply	other threads:[~2020-03-03 17:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 14:17 [PATCH RFC 0/9] KVM: Dirty ring support (QEMU part) Peter Xu
2020-02-05 14:17 ` [PATCH RFC 1/9] KVM: Fixup kvm_log_clear_one_slot() ioctl return check Peter Xu
2020-03-25 16:34   ` Dr. David Alan Gilbert
2020-03-25 17:43   ` Peter Xu
2020-02-05 14:17 ` [PATCH RFC 2/9] linux-headers: Update Peter Xu
2020-02-05 14:17 ` [PATCH RFC 3/9] memory: Introduce log_sync_global() to memory listener Peter Xu
2020-03-25 16:52   ` Dr. David Alan Gilbert
2020-03-25 17:02     ` Peter Xu
2020-02-05 14:17 ` [PATCH RFC 4/9] KVM: Create the KVMSlot dirty bitmap on flag changes Peter Xu
2020-03-25 17:44   ` Dr. David Alan Gilbert
2020-02-05 14:17 ` [PATCH RFC 5/9] KVM: Provide helper to get kvm dirty log Peter Xu
2020-03-25 17:52   ` Dr. David Alan Gilbert
2020-03-25 18:15     ` Peter Xu
2020-02-05 14:17 ` [PATCH RFC 6/9] KVM: Provide helper to sync dirty bitmap from slot to ramblock Peter Xu
2020-03-25 18:47   ` Dr. David Alan Gilbert
2020-02-05 14:17 ` [PATCH RFC 7/9] KVM: Cache kvm slot dirty bitmap size Peter Xu
2020-03-25 18:49   ` Dr. David Alan Gilbert
2020-02-05 14:17 ` [PATCH RFC 8/9] KVM: Add dirty-ring-size property Peter Xu
2020-03-25 20:00   ` Dr. David Alan Gilbert
2020-03-25 20:42     ` Peter Xu
2020-03-26 13:41       ` Dr. David Alan Gilbert
2020-03-26 16:03         ` Peter Xu
2020-03-25 20:14   ` Dr. David Alan Gilbert
2020-03-25 20:48     ` Peter Xu
2020-02-05 14:17 ` [PATCH RFC 9/9] KVM: Dirty ring support Peter Xu
2020-03-25 20:41   ` Dr. David Alan Gilbert
2020-03-25 21:32     ` Peter Xu
2020-03-26 14:14       ` Dr. David Alan Gilbert
2020-03-26 16:10         ` Peter Xu
2020-02-05 14:51 ` [PATCH RFC 0/9] KVM: Dirty ring support (QEMU part) no-reply
2020-03-03 17:32 ` Peter Xu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200303173224.GD464129@xz-x1 \
    --to=peterx@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.