Messages in this thread |  | | | Date | Mon, 02 Jul 2012 09:58:37 -0700 | | From | John Stultz <> | | Subject | Re: [PATCH] [RFC] Potential fix for leapsecond caused futex related load spikes |
| |
On 07/02/2012 03:16 AM, Richard Cochran wrote: > On Sun, Jul 01, 2012 at 10:28:25AM -0700, John Stultz wrote: >> Reworking the patch now. > John, > > I know you didn't like my (originally Michael Hack's) idea of keeping > time in TAI, but wouldn't changing to an internal, continuous time > scale (not necessary TAI) solve these sorts of timer issues? So first, I don't think keeping a different time base would have avoided this particular issue. Its really an issue where the hrtimer code has in-effect a cache of timekeeping state that, since clock_was_set() wasn't called, didn't get updated when we applied the leapsecond.
Second, I'm not opposed to reworking how the internal system keeps track of time. I just wasn't fond of specifics in your implementation (mostly around mixing cleanups with behavioural changes).
I wouldn't be opposed to something like: CLOCK_TAI = CLOCK_MONOTONIC + monotonic_to_tai CLOCK_REALTIME = CLOCK_TAI + tai_to_utc
Also, some of your suggested changes to move some of the NTP state into the timekeeper struct made sense as well, but just needed some slight tweaks.
> There have been a number of clock/timer/leap bugs over the last > years. Some of these might have been avoided by using a continuous > scale, since no special timer actions would be needed during a leap > second. Unfortunately the other issues have been locking related, so I don't think changing the internal time scale would have helped.
Regardless, I do hope you rework and resend your proposed changes. Clearly we could use more eyes in this area.
thanks -john
|  |