From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH 1/2] KVM: MMU: Mark sp mmio cached when creating mmio spte
Date: Wed, 13 Mar 2013 23:39:53 -0300
Message-ID: <20130314023953.GB18111@amt.cnet>
References: <20130312174440.5d5199ee.yoshikawa_takuya_b1@lab.ntt.co.jp>
 <5140094F.5080700@linux.vnet.ibm.com>
 <20130313162816.c62899dc.yoshikawa_takuya_b1@lab.ntt.co.jp>
 <51402DDA.607@linux.vnet.ibm.com>
 <20130313123358.GM11223@redhat.com>
 <51407441.4020200@linux.vnet.ibm.com>
 <20130313224056.8c9c87f4d95b332d2273a685@gmail.com>
 <514087A0.1000704@linux.vnet.ibm.com>
 <20130314015821.GA13261@amt.cnet>
 <20130314112641.e2ccbc6b.yoshikawa_takuya_b1@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
	Takuya Yoshikawa <takuya.yoshikawa@gmail.com>,
	Gleb Natapov <gleb@redhat.com>, kvm@vger.kernel.org
To: Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:58945 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755643Ab3CNCkT (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 13 Mar 2013 22:40:19 -0400
Content-Disposition: inline
In-Reply-To: <20130314112641.e2ccbc6b.yoshikawa_takuya_b1@lab.ntt.co.jp>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, Mar 14, 2013 at 11:26:41AM +0900, Takuya Yoshikawa wrote:
> On Wed, 13 Mar 2013 22:58:21 -0300
> Marcelo Tosatti <mtosatti@redhat.com> wrote:
> 
> > > > In zap_spte, don't we need to search the pointer to be removed from the
> > > > global mmio-rmap list?  How long can that list be?
> > > 
> > > It is not bad. On softmmu, the rmap list has already been long more than 300.
> > > On hardmmu, normally the mmio spte is not frequently zapped (just set not clear).
> 
> mmu_shrink() is an exception.
> 
> > > 
> > > The worst case is zap-all-mmio-spte that removes all mmio-spte. This operation
> > > can be speed up after applying my previous patch:
> > > KVM: MMU: fast drop all spte on the pte_list
> 
> My point is other code may need to care more about latency.
> 
> Zapping all mmio sptes can happen only when changing memory regions:
> not so latency severe but should be reasonably fast not to hold
> mmu_lock for a (too) long time.
> 
> Compared to that, mmu_shrink() may be called any time and adding
> more work to it should be avoided IMO.  It should return ASAP.

Good point.

> In general, we should try hard to keep ourselves from affecting
> unrelated code path for optimizing something.  The global pte
> list is something which can affect many code paths in the future.
> 
> 
> So, I'm fine with trying mmio-rmap once we can actually measure
> very long mmu_lock hold time by traversing shadow pages.
> 
> How about applying this first and then see the effect on big guests?

Works for me. Xiao?