Re: [PATCH 1/1 v2] KVM: Reduce mmu_lock contention during dirty logging by cond_resched()

[Takuya Yoshikawa <takuya.yoshikawa@gmail.com>]

On Sun, 29 Apr 2012 15:59:18 +0300
Avi Kivity <avi@redhat.com> wrote:

> > As we discussed before, we need to add some tricks to de-couple mmu_lock and
> > TLB flush.
> 
> Ok, let's discuss them (we can apply the patch independently).  Do you
> have something in mind?
> 

How about your own idea?

http://www.spinics.net/lists/kvm/msg68550.html
===
> > How about something like a sequence lock:
> >
> >
> >     spin_lock(mmu_lock)
> >     need_flush = write_protect_stuff();
> >     atomic_add(kvm->want_flush_counter, need_flush);
> >     spin_unlock(mmu_lock);
> >
> >     while ((done = atomic_read(kvm->done_flush_counter)) < (want =
> > atomic_read(kvm->want_flush_counter)) {
> >           kvm_make_request(flush)
> >           atomic_cmpxchg(kvm->done_flush_counter, done, want)
> >     }
> >
> > This (or maybe a corrected and optimized version) ensures that any
> > need_flush cannot pass the while () barrier, no matter which thread
> > encounters it first.  However it violates the "do not invent new locking
> > techniques" commandment.  Can we map it to some existing method?
> 
> There is no need to advance 'want' in the loop.  So we could do
> 
> /* must call with mmu_lock held */
> void kvm_mmu_defer_remote_flush(kvm, need_flush)
> {
>       if (need_flush)
>             ++kvm->flush_counter.want;
> }
> 
> /* may call without mmu_lock */
> void kvm_mmu_commit_remote_flush(kvm)
> {
>       want = ACCESS_ONCE(kvm->flush_counter.want)
>       while ((done = atomic_read(kvm->flush_counter.done) < want) {
>             kvm_make_request(flush)
>             atomic_cmpxchg(kvm->flush_counter.done, done, want)
>       }
> }
===

	Takuya