From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:45093)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RAkAV-0008Tn-MB
	for qemu-devel@nongnu.org; Mon, 03 Oct 2011 11:11:05 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RAkAQ-0003ZX-0D
	for qemu-devel@nongnu.org; Mon, 03 Oct 2011 11:10:59 -0400
Received: from mx1.redhat.com ([209.132.183.28]:19542)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RAkAP-0003ZP-GC
	for qemu-devel@nongnu.org; Mon, 03 Oct 2011 11:10:53 -0400
Message-ID: <4E89D078.3010301@redhat.com>
Date: Mon, 03 Oct 2011 17:10:48 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <20111002132436.GD11521@bow.tlv.redhat.com>
	<4E896FB7.7050708@redhat.com> <20111003083755.GC16798@bow>
In-Reply-To: <20111003083755.GC16798@bow>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Spice-devel] viewing continuous guest virtual
 memory as continuous in qemu
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Yonit Halperin <yhalperi@redhat.com>, qemu-devel@nongnu.org, spice-devel@freedesktop.org, Dave Airlie <airlied@redhat.com>

On 10/03/2011 10:37 AM, Alon Levy wrote:
> >
> >  Hi,
> >  won't there be an overhead for rendering on a non continuous
> >  surface? Will it be worthwhile comparing to not creating the
> >  surface?
>
> If I use a scatter-gather list there is overhead of allocating and
> copying the surface whenever I want to synchronize. Minimally once
> to copy from guest to host, and another copy from host to guest
> for any update_area. (we can only copy the required area.
>
> If I use page remapping like remap_file_pages does, I don't think
> there is any overhead for rendering. There is overhead for doing
> the remap_file_pages calls, but they are minimal (or so the man page
> says). I should benchmark this.

It's not trivial; and kvm and smp magnify the cost.  It shouldn't be 
done as part of normal rendering (setup is okay).

-- 
error compiling committee.c: too many arguments to function