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

[Paul Brook]

> > > > 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.
> 
> Did I say that? I take it back :) Real devices simply can not do things
> like atomic increment etc.  So all we really need is storing two bytes
> in memory

No. virtio requires an atomic store of the whole 16-bit value.

> > > 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.
> 
> _barrier implies atomic? Okay ... still, ordered with respect to what?
> Preceding stores? Following stores? loads?  All of the above?

All of the above.

> We can define such an API, but it's easier to misuse than a familiar and
> documented one IMO.

You're already using nonstandard APIs in the form of stw_phys. Even worse, 
you've made incorrect assumptions about the semantics of stw_phys.

> > >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?
> 
> With my patch datapath has a single read barrier, and a write barrier,
> but write barrier is a nop. If you make write barrier a read barrier,
> and add another barrier before operations, I expect about 4 times
> the number, so that will be what 8%?

I doubt it. I'd expect once you have one barrier the extras don't make a whole 
lot of difference. TBH I'm surprised they're significant at all except in 
maybe in very specific micro-benchmarks.

Paul