From: Jean Guyader <jean.guyader@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: James McKenzie <James.McKenzie@citrix.com>,
Ross Philipson <Ross.Philipson@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: V4V
Date: Fri, 25 May 2012 11:11:31 +0100 [thread overview]
Message-ID: <CAEBdQ93XMnrqQx7wc1gzSdZO+oA6auQmijU2yo2e9-KgSoOcbw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205251044140.26786@kaball-desktop>
On 25 May 2012 10:48, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
> On Thu, 24 May 2012, Jean Guyader wrote:
> > Some of the downsides to using the shared memory grant method:
> > - This method imposes an implicit ordering on domain destruction.
> > When this ordering is not honored the grantor domain cannot shutdown
> > while the grantee still holds references. In the extreme case where
> > the grantee domain hangs or crashes without releasing it granted
> > pages, both domains can end up hung and unstoppable (the DEADBEEF
> > issue).
>
> Is it still true? This looks like a serious issue.
>
I have tried to repro this issue the order day with libvchan but I
couldn't so it's probably fixed.
I suspect it has something to do with grant-ref and I don't think
libvchan uses grant refs.
>
> > - You can't trust any ring structures because the entire set of pages
> > that are granted are available to be written by the either guest.
> > - The PV connect/disconnect state-machine is poorly implemented.
> > There's no trivial mechanism to synchronize disconnecting/reconnecting
> > and dom0 must also allow the two domains to see parts of xenstore
> > belonging to the other domain in the process.
>
> We are starting to see this problem, trying to setup driver domains with
> libxl.
>
>
> > - Using the grant-ref model and having to map grant pages on each
> > transfer cause updates to V->P memory mappings and thus leads to
> > TLB misses and flushes (TLB flushes being expensive operations).
>
> [snip]
>
> > I've done some benchmarks on V4V and libchan and the results were
> > pretty close between the the two if you use the same buffer size in both cases.
>
> It is strange that you cannot see any performance advantages using v4v. I
> was expecting quite a difference, especially on new numa machines.
The numbers for both system were in the 50MB/s 60MB/s ranges from domU to domU.
That was on a out of the box testing on a desktop type machine I
didn't look at making
any kind of tricks or adjustment to make it go faster.
Jean
next prev parent reply other threads:[~2012-05-25 10:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 17:23 V4V Jean Guyader
2012-05-25 9:48 ` V4V Stefano Stabellini
2012-05-25 10:11 ` Jean Guyader [this message]
2012-05-25 10:16 ` V4V Stefano Stabellini
2012-05-25 10:19 ` V4V Pasi Kärkkäinen
2012-05-29 22:22 ` V4V Daniel De Graaf
2012-05-30 11:41 ` V4V Stefano Stabellini
2012-05-30 14:19 ` V4V Daniel De Graaf
2012-05-31 17:20 ` V4V Stefano Stabellini
2012-05-31 18:18 ` V4V Daniel De Graaf
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=CAEBdQ93XMnrqQx7wc1gzSdZO+oA6auQmijU2yo2e9-KgSoOcbw@mail.gmail.com \
--to=jean.guyader@gmail.com \
--cc=James.McKenzie@citrix.com \
--cc=Ross.Philipson@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).