From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: KVM: guest: only batch user pte updates Date: Wed, 11 Feb 2009 08:57:42 -0800 Message-ID: <49930386.7070509@goop.org> References: <20090210214532.GA4082@amt.cnet> <4991FD0D.1070108@goop.org> <20090210224141.GA4471@amt.cnet> <49920A68.5030408@goop.org> <4992BCD4.7040505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm-devel , Rusty Russell , Zachary Amsden To: Avi Kivity Return-path: Received: from gw.goop.org ([64.81.55.164]:48704 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753980AbZBKQ5p (ORCPT ); Wed, 11 Feb 2009 11:57:45 -0500 In-Reply-To: <4992BCD4.7040505@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Jeremy Fitzhardinge wrote: >>> >>> Yes. It seems however that only set_pte_at/pte_update/_defer are >>> used under significatly long lazy mmu sections (long as in number of >>> updates). Is it worthwhile to bother (and risk) batching kernel pte >>> updates ? >>> >> >> Well, that depends on how expensive each update is. For something >> like kunmap atomic, I think combining the clear+tlb flush probably is >> worthwhile. > > I agree, kmap_atomic() is fairly common. (Not that we're actually batching it at present; we need to work out proper semantics for nesting batches...) J