xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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).