[Qemu-devel] Re: [PATCH-RFC 0/3] qemu: memory barriers in virtio

[Paul Brook]

On Wednesday 23 December 2009, Michael S. Tsirkin wrote:
> On Wed, Dec 23, 2009 at 12:25:46PM +0000, Paul Brook wrote:
> > > > > So possibly this means that we
> > > > > could optimize the barrier away, but I don't think this amounts to
> > > > > a serious issue, I guess portability/readability is more important.
> > > >
> > > > The more important issue is that regular devices which to not require
> > > > coherency or ordering can omit this lock.
> > >
> > > So let them. What's the issue?
> >
> > The issue is that at you're only fixing half the problem. Barriers aren't
> > sufficient to get the semantics you need. You also need atomicity.
> >
> > Given we need both, why not actually defined an API that gives you this?
> 
> Because, I do not want to define APIs, I want to reuse an existing one.

Except that, say you said later in your email, no API exists for doing atomic 
accesses, so you need different code anyway.

> E.g. what is stw_barrier?  atomic read followed by a barrier?  read
> preceded by a barrier? and what kind of barrier? IMO

stw_barrier is an ordered atomic store.

>With KVM, even these partial barriers add small but measureable overhead
>(about 2%).

Now are you measuring that overhead? How much additional overhead does a full 
barrier incur?

Paul