From: Avi Kivity <avi@redhat.com>
To: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Cc: mtosatti@redhat.com, kvm@vger.kernel.org, takuya.yoshikawa@gmail.com
Subject: Re: [PATCH 4/4] KVM: Optimize dirty logging by rmap_write_protect()
Date: Mon, 14 Nov 2011 12:22:24 +0200 [thread overview]
Message-ID: <4EC0EBE0.6010802@redhat.com> (raw)
In-Reply-To: <20111114182450.d67f74ee.yoshikawa.takuya@oss.ntt.co.jp>
On 11/14/2011 11:24 AM, Takuya Yoshikawa wrote:
> Currently, write protecting a slot needs to walk all the shadow pages
> and checks ones which have a pte mapping a page in it.
>
> The walk is overly heavy when dirty pages in that slot are not so many
> and checking the shadow pages would result in unwanted cache pollution.
>
> To mitigate this problem, we use rmap_write_protect() and check only
> the sptes which can be reached from gfns marked in the dirty bitmap
> when the number of dirty pages are less than that of shadow pages.
>
> This criterion is reasonable in its meaning and worked well in our test:
> write protection became some times faster than before when the ratio of
> dirty pages are low and was not worse even when the ratio was near the
> criterion.
>
> Note that the locking for this write protection becomes fine grained.
> The reason why this is safe is descripted in the comments.
>
>
> +/**
> + * write_protect_slot - write protect a slot for dirty logging
> + * @kvm: the kvm instance
> + * @memslot: the slot we protect
> + * @dirty_bitmap: the bitmap indicating which pages are dirty
> + * @nr_dirty_pages: the number of dirty pages
> + *
> + * We have two ways to find all sptes to protect:
> + * 1. Use kvm_mmu_slot_remove_write_access() which walks all shadow pages and
> + * checks ones that have a spte mapping a page in the slot.
> + * 2. Use kvm_mmu_rmap_write_protect() for each gfn found in the bitmap.
> + *
> + * Generally speaking, if there are not so many dirty pages compared to the
> + * number of shadow pages, we should use the latter.
> + *
> + * Note that letting others write into a page marked dirty in the old bitmap
> + * by using the remaining tlb entry is not a problem. That page will become
> + * write protected again when we flush the tlb and then be reported dirty to
> + * the user space by copying the old bitmap.
> + */
> +static void write_protect_slot(struct kvm *kvm,
> + struct kvm_memory_slot *memslot,
> + unsigned long *dirty_bitmap,
> + unsigned long nr_dirty_pages)
> +{
> + /* Not many dirty pages compared to # of shadow pages. */
> + if (nr_dirty_pages < kvm->arch.n_used_mmu_pages) {
Seems a reasonable heuristic. In particular, this is always true for
vga, yes? That will get the code exercised.
> + unsigned long gfn_offset;
> +
> + for_each_set_bit(gfn_offset, dirty_bitmap, memslot->npages) {
> + unsigned long gfn = memslot->base_gfn + gfn_offset;
> +
> + spin_lock(&kvm->mmu_lock);
> + kvm_mmu_rmap_write_protect(kvm, gfn, memslot);
> + spin_unlock(&kvm->mmu_lock);
> + }
> + kvm_flush_remote_tlbs(kvm);
> + } else {
> + spin_lock(&kvm->mmu_lock);
> + kvm_mmu_slot_remove_write_access(kvm, memslot->id);
> + spin_unlock(&kvm->mmu_lock);
> + }
> +}
> +
>
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-11-14 10:22 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 9:20 [PATCH 0/4] KVM: Dirty logging optimization using rmap Takuya Yoshikawa
2011-11-14 9:21 ` [PATCH 1/4] KVM: MMU: Clean up BUG_ON() conditions in rmap_write_protect() Takuya Yoshikawa
2011-11-14 9:22 ` [PATCH 2/4] KVM: MMU: Split gfn_to_rmap() into two functions Takuya Yoshikawa
2011-11-14 9:23 ` [PATCH 3/4] KVM: Count the number of dirty pages for dirty logging Takuya Yoshikawa
2011-11-14 10:07 ` Avi Kivity
2011-11-14 10:24 ` Avi Kivity
2011-12-20 4:29 ` Takuya Yoshikawa
2011-12-23 11:14 ` Marcelo Tosatti
2011-12-24 2:52 ` Takuya Yoshikawa
2011-12-27 13:50 ` Marcelo Tosatti
2011-12-27 14:03 ` Avi Kivity
2011-12-27 15:03 ` Takuya Yoshikawa
2011-12-27 15:06 ` Avi Kivity
2011-12-27 15:15 ` Takuya Yoshikawa
2011-12-27 15:18 ` Avi Kivity
2011-11-14 9:24 ` [PATCH 4/4] KVM: Optimize dirty logging by rmap_write_protect() Takuya Yoshikawa
2011-11-14 10:22 ` Avi Kivity [this message]
2011-11-14 10:29 ` Takuya Yoshikawa
2011-11-14 10:25 ` [PATCH 0/4] KVM: Dirty logging optimization using rmap Avi Kivity
2011-11-14 10:56 ` Takuya Yoshikawa
2011-11-14 12:39 ` Avi Kivity
2011-11-16 4:28 ` Takuya Yoshikawa
2011-11-16 9:06 ` Avi Kivity
2011-11-29 10:01 ` Xiao Guangrong
2011-11-29 10:09 ` Xiao Guangrong
2011-11-29 10:35 ` Takuya Yoshikawa
2011-11-29 11:20 ` Avi Kivity
2011-11-29 11:56 ` Xiao Guangrong
2011-11-29 12:01 ` Avi Kivity
2011-11-29 14:03 ` Avi Kivity
2011-11-30 5:02 ` Takuya Yoshikawa
2011-11-30 5:02 ` [Qemu-devel] " Takuya Yoshikawa
2011-11-30 5:15 ` Takuya Yoshikawa
2011-11-30 5:15 ` [Qemu-devel] " Takuya Yoshikawa
2011-12-01 15:18 ` Avi Kivity
2011-12-01 15:18 ` [Qemu-devel] " Avi Kivity
2011-12-03 4:37 ` Takuya Yoshikawa
2011-12-03 4:37 ` [Qemu-devel] " Takuya Yoshikawa
2011-12-04 10:20 ` Avi Kivity
2011-12-04 10:20 ` [Qemu-devel] " Avi Kivity
2011-11-30 7:10 ` Xiao Guangrong
2011-11-30 7:03 ` Xiao Guangrong
2011-12-01 15:11 ` Avi Kivity
2011-11-16 8:17 ` Takuya Yoshikawa
2011-11-16 8:17 ` [Qemu-devel] " Takuya Yoshikawa
2011-11-17 9:28 ` Avi Kivity
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=4EC0EBE0.6010802@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=takuya.yoshikawa@gmail.com \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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.