From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Defer remote tlb flushes on invlpg (v3) Date: Thu, 19 Mar 2009 16:03:07 +0200 Message-ID: <49C2509B.5060607@redhat.com> References: <1237468666-30700-1-git-send-email-avi@redhat.com> <49C24C9C.9080101@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Andrea Arcangeli , kvm@vger.kernel.org To: Andrew Theurer Return-path: Received: from mx2.redhat.com ([66.187.237.31]:43596 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753856AbZCSODO (ORCPT ); Thu, 19 Mar 2009 10:03:14 -0400 In-Reply-To: <49C24C9C.9080101@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Andrew Theurer wrote: > Avi Kivity wrote: >> KVM currently flushes the tlbs on all cpus when emulating invlpg. This >> is because at the time of invlpg we lose track of the page, and leaving >> stale tlb entries could cause the guest to access the page when it is >> later freed (say after being swapped out). >> >> However we have a second change to flush the tlbs, when an mmu >> notifier is >> called to let us know the host pte has been invalidated. We can safely >> defer the flush to this point, which occurs much less frequently. Of >> course, >> we still do a local tlb flush when emulating invlpg. >> > I should be able to run some performance comparisons with this in the > next day or two. Excellent. Note that while this does not improve performance relative to released versions of kvm; rather it undoes a performance regression caused by 967f61 ("KVM: Fix missing smp tlb flush in invlpg"), which fixes a memory corruption problem. The workloads which will exercise this are mmu-intensive smp workloads with CONFIG_HIGHMEM (or CONFIG_HIGHMEM64) guests; 32-bit RHEL 3 is a pretty bad offender. -- error compiling committee.c: too many arguments to function