qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: [PATCH-RFC 0/3] qemu: memory barriers in virtio
Date: Wed, 23 Dec 2009 18:28:44 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Wed, Dec 23, 2009 at 03:13:05PM +0000, Paul Brook wrote:
> > > > > 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.

Yes. This is achieved by
void stw_atomic(uint16_t *p, uint16_t v)
{
        *p = v;
}
on all hosts of interest.

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

It's not obvious from the name, and we don't need 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.

This patch is not making any new assumptions.  virtio code was not
written by me, and it comes before kvm smp/iothread I think, so it is
making assumptions which in theory might not be valid there.  But in
practice they are valid, mostly by luck.

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

I was concerned that people would complain about adding barriers
that TCG does not need, bt apparently that is not of concern.
So I don't understand what is? Why should I randomly spread
barrier calls all over the code? If they are needed, tell me
why they are, and I will add them overhead or not.

-- 
MST




reply via email to

[Prev in Thread] Current Thread [Next in Thread]