Re: [RFC][PATCH 5/7] x86: Use latch data structure for cyc2ns

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Nov 29, 2013 at 03:22:45PM -0800, Andy Lutomirski wrote:
> On Fri, Nov 29, 2013 at 9:37 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > Use the 'latch' data structure for cyc2ns.
> >
> > This is a data structure first proposed by me and later named by
> > Mathieu. If anybody's got a better name; do holler.
> 
> That structure must exist in the literature, but I have no idea what
> it's called.  It's a multi-word lock-free atomic (I think -- maybe
> it's just regular) register.  I even published a considerably fancier
> version of much the same thing a few years ago.  :)

Yeah, its a fairly straight fwd thing it has to be named someplace ;-)

> I've occasionally wondered whether it would be possible to make a
> monotonicity-preserving version of this and use it for clock_gettime.
> One approach: have the writer set the time for the update to be a bit
> in the future and have the reader compare the current raw time to the
> cutoff to see which set of frequency/offset to use.  (This requires
> having some kind of bound on how long it takes to update the data
> structures.)
> 
> The advantage: clock_gettime would never block.
> The disadvantage: complicated, potentially nasty to implement, and it
> would get complicated if anyone tried to allow multiple updates in
> rapid succession.

Yes, that way you can chain a number of linear segments in various
slots, but you're indeed right in that it will limit the update
frequency. More slots will give you more room, but eventually you're
limited.

I suppose NTP is the primary updater in that case, does that have a
limit on the updates? All the other updates we can artificially limit,
that shouldn't really matter.

But yeah in my case we pretty much assume the TSC is complete crap and a
little more crap simply doesn't matter.

For the 'stable' tsc on modern machines we never set the frequency and
it doesn't matter anyway.