Re: [Xen-devel] V4V

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 25 May 2012, Jean Guyader wrote:
> On 25 May 2012 10:48, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> 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.

I suspect that the same test on a machine with 32 cpus and 4-8 numa
nodes would have given different results.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel