Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 5 Jun 2015, Peter Zijlstra wrote:

> On Fri, 2015-06-05 at 11:04 +0200, Richard Cochran wrote:
> > On Fri, Jun 05, 2015 at 09:29:13AM +0200, Peter Zijlstra wrote:
> > > That leaves the question; for who is this exact second edge important?
> > 
> > Distributed applications using the UTC time scale.
> > 
> > Many control applications are done with a 1 millisecond period.
> > Having the time wrong by a second for 10 or 100 loops is bad news.
> 
> Firstly I would strongly suggest such applications not use UTC because
> of this, I think TAI was invented for just this reason.
> 
> Secondly, how would John's patches help with this? Usespace loops
> reading time would be using the VDSO and would still not get the right
> time, and timers would be subject to the same IRQ latency that a hrtimer
> based leap second insert would, and would still very much not be in-sync
> across the cluster.

So the only thing which is fixed are in kernel users and therefor
hrtimers. 

That means the whole leap mess added into the gettime fast path is
just constant overhead for that corner case.

We can be smarter than that and just block hrtimer delivery for clock
realtime timers across the leap edge. There should be ways to do that
non intrusive if we think hard enough about it.

Thanks,

	tglx