lkml.org 
[lkml]   [2011]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFT/PATCH v2 2/6] x86-64: Optimize vread_tsc's barriers

* 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


\
 
 \ /
  Last update: 2011-04-07 22:35    [W:0.656 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site