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