From: Avi Kivity <avi@redhat.com>
To: Yonit Halperin <yhalperi@redhat.com>,
qemu-devel@nongnu.org, spice-devel@freedesktop.org,
Dave Airlie <airlied@redhat.com>
Subject: Re: [Qemu-devel] [Spice-devel] viewing continuous guest virtual memory as continuous in qemu
Date: Mon, 03 Oct 2011 17:10:48 +0200 [thread overview]
Message-ID: <4E89D078.3010301@redhat.com> (raw)
In-Reply-To: <20111003083755.GC16798@bow>
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
next prev parent reply other threads:[~2011-10-03 15:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-02 13:24 [Qemu-devel] viewing continuous guest virtual memory as continuous in qemu Alon Levy
2011-10-02 14:31 ` [Qemu-devel] [Spice-devel] " Alon Levy
2011-10-02 17:12 ` Avi Kivity
2011-10-03 7:49 ` Alon Levy
2011-10-03 8:17 ` Yonit Halperin
2011-10-03 8:37 ` Alon Levy
2011-10-03 8:49 ` Alon Levy
2011-10-03 15:10 ` Avi Kivity [this message]
2011-10-11 11:28 ` Gerd Hoffmann
2011-10-11 12:21 ` Alon Levy
2011-10-11 13:20 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E89D078.3010301@redhat.com \
--to=avi@redhat.com \
--cc=airlied@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=spice-devel@freedesktop.org \
--cc=yhalperi@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.