From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [patch 03/10] KVM: switch dirty_log to mmu_lock protection
Date: Tue, 22 Sep 2009 09:44:15 -0300 [thread overview]
Message-ID: <20090922124415.GB3138@amt.cnet> (raw)
In-Reply-To: <4AB870BF.4090905@redhat.com>
On Tue, Sep 22, 2009 at 09:37:51AM +0300, Avi Kivity wrote:
> On 09/22/2009 02:37 AM, Marcelo Tosatti wrote:
>> get_dirty_log vs mark_page_dirty need to be mutually exclusive. Switch
>> to mmu_lock protection.
>>
>>
>
> I'm not sure all archs use mmu_lock. Also, I'm unhappy about
> introducing more use (especially as it's often unnecessary, if dirty
> logging is turned off for the slot for example).
True.
> I think you can use rcu for this as well. When you read the log,
> allocate a new empty bitmap, switch the memslots pointer to include it,
> and synchronize_srcu(). Now we are certain everyone is using the new
> bitmap we can copy the old one to usespace and delete it.
This will slow down get_dirty_log, which can lead to regressions in
migration and poorer vga refresh updates.
Moreover, since updates are running concurrently, at the time
synchronize_srcu returns you can have plenty of dirty data in the new
bitmap which is not the case with mutual exclusion.
This are the reasons for the choice. Would you prefer a new rw lock?
next prev parent reply other threads:[~2009-09-22 12:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-21 23:37 [patch 00/10] RFC: switch vcpu context to use SRCU Marcelo Tosatti
2009-09-21 23:37 ` [patch 01/10] KVM: modify memslots layout in struct kvm Marcelo Tosatti
2009-09-21 23:37 ` [patch 02/10] KVM: modify alias layout in x86s struct kvm_arch Marcelo Tosatti
2009-09-21 23:37 ` [patch 03/10] KVM: switch dirty_log to mmu_lock protection Marcelo Tosatti
2009-09-22 6:37 ` Avi Kivity
2009-09-22 12:44 ` Marcelo Tosatti [this message]
2009-09-22 12:52 ` Avi Kivity
2009-09-21 23:37 ` [patch 04/10] KVM: split kvm_arch_set_memory_region into prepare and commit Marcelo Tosatti
2009-09-22 6:40 ` Avi Kivity
2009-09-21 23:37 ` [patch 05/10] KVM: introduce gfn_to_pfn_memslot Marcelo Tosatti
2009-09-21 23:37 ` [patch 06/10] KVM: use gfn_to_pfn_memslot in kvm_iommu_map_pages Marcelo Tosatti
2009-09-21 23:37 ` [patch 07/10] KVM: introduce kvm->srcu and convert kvm_set_memory_region to SRCU update Marcelo Tosatti
2009-09-22 6:59 ` Avi Kivity
2009-09-22 16:16 ` Marcelo Tosatti
2009-09-22 10:40 ` Fernando Carrijo
2009-09-22 12:55 ` Marcelo Tosatti
2009-09-24 14:06 ` Marcelo Tosatti
2009-09-24 17:28 ` Paul E. McKenney
2009-09-24 18:05 ` Marcelo Tosatti
2009-09-25 15:05 ` Avi Kivity
2009-09-21 23:37 ` [patch 08/10] KVM: x86: switch kvm_set_memory_alias " Marcelo Tosatti
2009-09-22 7:04 ` Avi Kivity
2009-09-21 23:37 ` [patch 09/10] KVM: convert io_bus to SRCU Marcelo Tosatti
2009-09-21 23:37 ` [patch 10/10] KVM: switch vcpu context to use SRCU Marcelo Tosatti
2009-09-22 7:07 ` Avi Kivity
2009-09-22 7:09 ` [patch 00/10] RFC: " 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=20090922124415.GB3138@amt.cnet \
--to=mtosatti@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).