From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlfzF-0007cV-V0 for qemu-devel@nongnu.org; Tue, 26 Jul 2011 07:39:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlfzE-0002Qv-Sw for qemu-devel@nongnu.org; Tue, 26 Jul 2011 07:39:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlfzE-0002Qk-Ls for qemu-devel@nongnu.org; Tue, 26 Jul 2011 07:39:44 -0400 Message-ID: <4E2EA77C.1080207@redhat.com> Date: Tue, 26 Jul 2011 14:39:40 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1311602584-23409-1-git-send-email-avi@redhat.com> <1311602584-23409-15-git-send-email-avi@redhat.com> <4E2DC10A.4040005@codemonkey.ws> <4E2E9B66.1080308@redhat.com> In-Reply-To: <4E2E9B66.1080308@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/23] memory: transaction API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/26/2011 01:48 PM, Avi Kivity wrote: > On 07/25/2011 10:16 PM, Anthony Liguori wrote: >> On 07/25/2011 09:02 AM, Avi Kivity wrote: >>> Allow changes to the memory hierarchy to be accumulated and >>> made visible all at once. This reduces computational effort, >>> especially when an accelerator (e.g. kvm) is involved. >>> >>> Useful when a single register update causes multiple changes >>> to an address space. >>> >>> Signed-off-by: Avi Kivity >> >> What's the motivation for this? Was this just because it seemed neat >> to do or did you run into a performance issue you were trying to solve? > > Both cirrus and 440fx need this; look at > i440fx_update_memory_mappings() for example, it blindly updates > mappings even for PAMs which haven't changed. > > These issues can be also solved by more care on the caller's side, or > by making the API richer, but it's good to have a no-thought-required > solution, particularly as it's so easy to do. > I should note that updating the memory map is relatively slow with kvm due to the need to wait for an rcu grace period; though recent kernels are faster. So any saving here has a large effect. -- error compiling committee.c: too many arguments to function