From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH 0/8] KVM: Reduce mmu_lock hold time when zapping mmu pages Date: Wed, 23 Jan 2013 21:45:23 +0800 Message-ID: <50FFE973.30709@linux.vnet.ibm.com> References: <20130123191231.d66489d2.yoshikawa_takuya_b1@lab.ntt.co.jp> <50FFBF24.3000203@linux.vnet.ibm.com> <20130123222846.05bfc05a91ee133bd25981d6@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , mtosatti@redhat.com, gleb@redhat.com, kvm@vger.kernel.org To: Takuya Yoshikawa Return-path: Received: from e28smtp03.in.ibm.com ([122.248.162.3]:47226 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754364Ab3AWNpe (ORCPT ); Wed, 23 Jan 2013 08:45:34 -0500 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 Jan 2013 19:13:56 +0530 Received: from d28relay04.in.ibm.com (d28relay04.in.ibm.com [9.184.220.61]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 8DBB5394004D for ; Wed, 23 Jan 2013 19:15:29 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0NDjOaq65208484 for ; Wed, 23 Jan 2013 19:15:24 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0NDjOaU030975 for ; Thu, 24 Jan 2013 00:45:25 +1100 In-Reply-To: <20130123222846.05bfc05a91ee133bd25981d6@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/23/2013 09:28 PM, Takuya Yoshikawa wrote: > On Wed, 23 Jan 2013 18:44:52 +0800 > Xiao Guangrong wrote: > >> On 01/23/2013 06:12 PM, Takuya Yoshikawa wrote: >>> This patch set mitigates another mmu_lock hold time issue. Although >>> this is not enough and I'm thinking of additional work already, this >>> alone can reduce the lock hold time to some extent. >>> >> >> It is not worth doing this kind of complex thing, usually, only a few pages on >> the invalid list. The *really* heavily case is kvm_mmu_zap_all() which can be speeded >> up by using generation number, this is a todo work in kvm wiki: > > I don't think this is so complex. This is a basic programming technique > using linked lists. I just consider that only a few page exist on the invalid list, no worth introducing this. > > The current code which deletes the two link nodes in different functions > looks unnatural to me: traversing the sp->link nodes forces us to break > the loop and sp->hash_link nodes alone is allowed to continue ... > > Making each function semantically clear should be more important than > other things. > The reason the code like this is, we have lockless shadow page walker. > But maybe a matter of taste, so I'll wait for the maintainers' comments. > >> http://www.linux-kvm.org/page/TODO: O(1) mmu invalidation using a generation number >> >> I am doing this work for some weeks and will post the patch out during these days. > > I remember that Avi originally wrote the idea of introducing the > generation of mmu pages in his other work. > Whatever the original consideration is, the idea can speed up mmu invalidation a lot. (Actually, i mentioned this idea to you when discussion fast write protect long time ago.)