From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: [PATCH 1/2] KVM: mmu_notifier: Flush TLBs before releasing mmu_lock Date: Mon, 13 Feb 2012 15:00:41 +0900 Message-ID: <4F38A709.10302@oss.ntt.co.jp> References: <20120210152831.6ac3ac87.yoshikawa.takuya@oss.ntt.co.jp> <4F34CCD1.6050103@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org, aarcange@redhat.com To: Xiao Guangrong Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:59588 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751796Ab2BMF6t (ORCPT ); Mon, 13 Feb 2012 00:58:49 -0500 In-Reply-To: <4F34CCD1.6050103@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: (2012/02/10 16:52), Xiao Guangrong wrote: > On 02/10/2012 02:28 PM, Takuya Yoshikawa wrote: > >> Other threads may process the same page in that small window and skip >> TLB flush and then return before these functions do flush. >> > > > It is possible that flush tlb in mmu lock only when writeable > spte is invalided? Sometimes, kvm_flush_remote_tlbs need > long time to wait. > I am sorry but I don't see the point of adding yet another complexity for that. OK, let me clarify my position. When I made this patch, I did a simple test to see if mmu notifier would work normally after my patch applied: I allocated large memory behind the guest and made the host call mmu_notifier functions. In that situation the host as a whole became slow, e.g. I saw really bad response for some seconds. In such a case, do you mind the additional time VCPU threads may have to wait until the mmu notifier finishes the flush, only when they are trying to take the mmu_lock? Takuya