From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKXsJ-0003d4-7J for qemu-devel@nongnu.org; Thu, 12 May 2011 11:32:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QKXsH-0001UF-CW for qemu-devel@nongnu.org; Thu, 12 May 2011 11:32:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKXsH-0001Tl-4r for qemu-devel@nongnu.org; Thu, 12 May 2011 11:32:25 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4CFWOJ4021616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 May 2011 11:32:24 -0400 Message-ID: <4DCBFD84.9040702@redhat.com> Date: Thu, 12 May 2011 18:32:20 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1304441374-27314-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1304441374-27314-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] introduce cpu_physical_memory_map_fast List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 05/03/2011 07:49 PM, Paolo Bonzini wrote: > Paravirtualized devices (and also some real devices) can assume they > are going to access RAM. For this reason, provide a fast-path > function with the following properties: > > 1) it will never allocate a bounce buffer > > 2) it can be used for read-modify-write operations > > 3) unlike qemu_get_ram_ptr, it is safe because it recognizes "short" blocks > > Patches 3 and 4 use this function for virtio devices and the milkymist > GPU. The latter is only compile-tested. > > Another function checks if it is possible to split a contiguous physical > address range into multiple subranges, all of which use the fast path. > I will introduce later a use for this function. > Out of curiosity, what performance benefit do you see? For relatively constant mappings (like the ring) we can cache the mapping in structure and invalidate it when the memory map changes (using, say, rcu). That doesn't work for the actual buffers, or for indirect mappings. -- error compiling committee.c: too many arguments to function