From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] memory: transaction API Date: Thu, 21 Jul 2011 15:08:58 +0300 Message-ID: <4E2816DA.9060704@redhat.com> References: <1311243679-18403-1-git-send-email-avi@redhat.com> <4E280195.5040003@siemens.com> <4E281609.7090809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56213 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751754Ab1GUMJE (ORCPT ); Thu, 21 Jul 2011 08:09:04 -0400 In-Reply-To: <4E281609.7090809@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/21/2011 03:05 PM, Avi Kivity wrote: > On 07/21/2011 01:38 PM, Jan Kiszka wrote: >> On 2011-07-21 12:21, 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. >> >> That's simple to implement in the core, but complicates life for the >> users, at least for the simple "update this region" use case. >> > > Why? just stick a _begin() and _commit() at the start and end of the > update_mapping() function. It's an optional API, for simple cases > (like mapping a BAR) you don't have to use it. > Do you see an improvement if you change cirrus_update_memory_access() in this fashion? -- error compiling committee.c: too many arguments to function