Re: [RFT/PATCH v2 2/6] x86-64: Optimize vread_tsc's barriers

[Ingo Molnar <mingo@elte.hu>]

* Andi Kleen <andi@firstfloor.org> wrote:

> > So the much better optimization would be to give up on exact GTOD coherency 
> > and just make sure the same task does not see time going backwards. If 
> > user-space wants precise coherency it can use synchronization primitives 
> > itsef. By default it would get the fast and possibly off by a few cycles 
> > thing instead. We'd never be seriously jump in time - only small jumps 
> > would happen in practice, depending on CPU parallelism effects.
> 
> That would be a big user visible break in compatibility.

Those are big scary words, but you really need to think this through:

Firstly, what is the user expectation? That a GTOD timestamp is provided. What 
will the user application do with that timestamp? Store it, for later use.

So there's implicit ordering all around these timestamps.

Secondly, x86 hardware never did a good job keeping our GTOD timestamps 
coherent, so while there *is* expectation for certainl behavior (Andy's for 
example), it's not widespread at all.

I bet that Linus's single-side barrier approach will be good enough in practice 
to meet Andy's needs. We might not be able to remove both barriers, but the 
tricks look really fragile ...

Andy, mind trying out Linus's suggestion? It should bring us more of a speedup 
and it would keep this code even simpler.

Thanks,

	Ingo