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

[Ingo Molnar]

* John Stultz <john.stultz@xxxxxxxxxx> wrote:

> > [...]
> >
> > but the long term trend still dominates. Look at this graph of measurements of the
> > Earth's rotation:
> >
> >   http://en.wikipedia.org/wiki/File:Deviation_of_day_length_from_SI_day.svg
> >
> > See how the mean (the green line) was always above zero in the measured past. The
> > monotonically increasing nature comes from that.
> >
> > and given how many problems we had with leap second insertion, on millions of
> > installed systems, guess the likelihood of there being a leap second deleted? How
> > many OSs that can do leap second insertion are unable to do leap second deletion?
> >
> > Also note that leap second deletion means a jump in time backward. Daylight saving
> > time is already causing problems with that.
> 
> Err.. Other way around. Leap-second deletion is a jump in time forward (jumping 
> from 23:59:58 to 00:00:00, skipping 23:59:59). Which is simpler to deal with. 
> [...]

Indeed!

Still my point remains: many OSs that can handle leap second insertion don't 
handle leap second deletion, so what are the chances that even a temporary blip in 
earth's rotation (which will be offset by the long term trend within a year or so 
after the event) will cause a conservative international standards body to declare 
an unprecedented leap second deletion? Fairly low I'd say.

> [...] And luckily (at least for us) daylight savings is done in userspace (as 
> UTC, including leapseconds, ideally would be from the kernel providing TAI 
> time).
> 
> But yes, I agree that the leap deletion logic is likely to never run outside of 
> testing.

Which is a red flag.

> > [...]
> >
> > So why make the code more fragile, more complex, just to solve a scenario that 
> > cannot really be done perfectly?
> 
> So here I worry I didn't communicate clearly enough what the patch does. :(
> 
> Its not about making interrupts more accurate around the leapsecond, its about 
> applying the leapsecond transition in the read-path precisely at the leapsecond 
> edge (rather then a short while later when the timer fires and we update the 
> timekeeping structures).
> 
> But more importantly, this change to the read path prevents timers that may be 
> expired before update_wall_time timer runs (most likely on other cpus) from 
> being expired early. Since the time read that is used by the hrtimer expiration 
> logic is adjusted properly right on that edge.

But with leap second smearing we'd have the same benefits and some more.

> > Especially as second smearing appears to be the way superior future method of 
> > handling leap seconds.
> 
> So here the problem is it depends on the user. For probably most users, who 
> really don't care, the leap-smear is ideal behavior for CLOCK_REALTIME (I think 
> leap-smears causing any change to other clockids would be surprising). However, 
> there are some users who expect posix UTC leapsecond behavior. Either because 
> they're positioning telescopes doing things that do depend on strict solar time, 
> or because they are required (in some cases by law) to use UTC.

That usecase is perfectly OK: they can use the old leap second logic.

What I argue is that we should not add significant complexity to logic that is 
fragile already as-is, and which runs at most only once per year.

> I don't think we can just abandon/break those users, for leap-smearing. So I 
> don't know if we can get away from that complexity.

That's a false dichotomy - I'm not suggesting to 'abandon' them.

I'm suggesting one of these options:

  - Keep the current leap second code as-is, because it's proven. Concentrate on 
    leap second smearing instead that is superior and which might emerge as a 
    future standard.

  - or make leap second insertion much more obvious and easier to verify (i.e. not
    a +100 LOC delta!)

  - or make leap second handling a part of some other existing facility that is
    used much more frequently: for example have you considered making it a
    special, kernel-internal case of settimeofday()? If settimeofday was
    implemented in a fashion to set the time at a given 'time edge', then
    thousands of systems would test that facility day in and out. Leap second
    insertion would simply be a special settimeofday() call that sets the time
    back by one second at midnight June 30 or so. Normal settimeofday() would be a
    call that sets the time back (or forward) at the next seconds edge right now -
    but it would fundamentally use the same facility.

    and yes, this variant would necessarily complicate settimeofday(), but that's
    OK, as it's used so frequently so we have adequate testing of it.

    A third facility would effectiely be merged with this as well: when NTP
    adjusts large offsets (when running with -g, etc.) it will use settimeofday(),
    right?

I don't think we've exhausted all of these options.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/