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: Tue, 1 May 2012 22:14:25 +0900
Message-ID: <20120501221425.105eb68a2d6da2748a6e82ff@gmail.com>
References: <20120428190544.7dc2bfd281054c1fcac5a14e@gmail.com>
	<20120428190754.5c27325da5663e5d8c9b9be1@gmail.com>
	<4F9D25A2.7020303@redhat.com>
	<20120429211759.0265df80d7193048344ff35b@gmail.com>
	<4F9D3B26.7090602@redhat.com>
	<20120429232407.684da454a0862f121754a126@gmail.com>
	<4F9D52A7.8020105@redhat.com>
	<20120429235550.856ff62eff954caf9ea739b5@gmail.com>
	<20120501030447.GA11921@amt.cnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org,
	yoshikawa.takuya@oss.ntt.co.jp
To: Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-pb0-f46.google.com ([209.85.160.46]:36546 "EHLO
	mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756345Ab2EANOa (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 1 May 2012 09:14:30 -0400
Received: by pbbrp8 with SMTP id rp8so4382618pbb.19
        for <kvm@vger.kernel.org>; Tue, 01 May 2012 06:14:30 -0700 (PDT)
In-Reply-To: <20120501030447.GA11921@amt.cnet>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Tue, 1 May 2012 00:04:47 -0300
Marcelo Tosatti <mtosatti@redhat.com> wrote:

> > Looking forward to it!
> > After your work, 8192 in my patch may better be lowered a bit.
> 
> Why not simply use spin_is_contented again? Are you afraid of
> GET_DIRTY_LOG starved by pagefaults?

No, but not so confident.

I personally tested some extreme cases like "cond_resched for every
iteration" and did not see any significant slowdown.  That's all what
I know now.


I also think we should use spin_is_contended() again.

What I am thinking now is whether it is possible to change
cond_resched_lock() to satisfy our need like:

	cond_resched_lock(lock, spin_is_contended(lock)); // we want this
	cond_resched_lock(lock, spin_needbreak(lock));    // same as current
	cond_resched_lock(lock, false);            // never check contention

Although I have checked all callers, it is not certain whether they do
not want to check lock contention when CONFIG_PREEMPT=no.

I will send an RFC patch to get comments, if possible.

Thanks,
	Takuya