From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: make kvm_mmu_zap_page() return the number of pages it actually freed. Date: Thu, 06 May 2010 12:30:55 +0300 Message-ID: <4BE28C4F.50209@redhat.com> References: <4BE0C3F5.1010907@cn.fujitsu.com> <4BE286EA.3070206@redhat.com> <4BE28B04.2010305@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org To: Gui Jianfeng Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45897 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755364Ab0EFJa7 (ORCPT ); Thu, 6 May 2010 05:30:59 -0400 In-Reply-To: <4BE28B04.2010305@cn.fujitsu.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/06/2010 12:25 PM, Gui Jianfeng wrote: > Avi Kivity wrote: > >> On 05/05/2010 04:03 AM, Gui Jianfeng wrote: >> >>> Currently, kvm_mmu_zap_page() returning the number of freed children sp. >>> This might confuse the caller, because caller don't know the actual freed >>> number. Let's make kvm_mmu_zap_page() return the number of pages it >>> actually >>> freed. >>> >>> >>> >> if (kvm_mmu_zap_page(kvm, sp)) >> goto restart; >> >> Needs to be updated. >> > Hi Avi, > > if kvm_mmu_zap_page() returns 1, we don't know whether the freed sp is the one we passes into > or the child. So here just restart hash walk as long as kvm_mmu_zap_page() returning a positive > number, although sometimes un-needed hash walk will happen. This fix gets code simpler, the > idea comes from Marcelo. > I see. Note this can invoke quadratic behaviour. I'll apply the patch, but we need to improve this area. -- error compiling committee.c: too many arguments to function