From mboxrd@z Thu Jan  1 00:00:00 1970
From: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Subject: Re: [PATCH 1/1 v2] KVM: Reduce mmu_lock contention during dirty
 logging by cond_resched()
Date: Sun, 29 Apr 2012 23:24:07 +0900
Message-ID: <20120429232407.684da454a0862f121754a126@gmail.com>
References: <20120428190544.7dc2bfd281054c1fcac5a14e@gmail.com>
	<20120428190754.5c27325da5663e5d8c9b9be1@gmail.com>
	<4F9D25A2.7020303@redhat.com>
	<20120429211759.0265df80d7193048344ff35b@gmail.com>
	<4F9D3B26.7090602@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mtosatti@redhat.com, kvm@vger.kernel.org,
	yoshikawa.takuya@oss.ntt.co.jp
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-pb0-f46.google.com ([209.85.160.46]:54291 "EHLO
	mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753859Ab2D2OYM (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 29 Apr 2012 10:24:12 -0400
Received: by pbbrp8 with SMTP id rp8so2376893pbb.19
        for <kvm@vger.kernel.org>; Sun, 29 Apr 2012 07:24:11 -0700 (PDT)
In-Reply-To: <4F9D3B26.7090602@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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