On Sat, Jun 6, 2015 at 2:44 AM, Thomas Gleixner <t...@linutronix.de> wrote: > 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.
Well, for vdso systems, hrtimers and adjtimex (which is the only interface that provides enough information to understand where in a leapsecond you actually are). And again, vdsos are fixable, but I hesitated due to my concerns about the extra performance overhead, the smaller benefit it provides relative to not having timers expiring early. > 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. This approach seems like it would add more work to the timer-add function (to check leapstate and adjust the expiration), which might be a heavier use case (we adjust for each timer) then the similar logic done in the update_base_offsets_now() at hrtimer_interrupt time (adjust for each hrtimer_interrupt). Now, It could be possible to do a lighter weight version of my patch, which just does the adjustment only for the hrtimer_interrupt code (leaving the rest of the read paths alone). If that is something you'd prefer. I'll have to think a bit to ensure the internal inconsistency isn't otherwise problematic. Though I suspect fixing adjtimex is worth it as well, since its really the only interface that can provide a sane view of the leapsecond, and isn't normally considered a hot path. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/