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
