On Mon, 8 Jun 2015, Thomas Gleixner wrote:
> On Mon, 8 Jun 2015, John Stultz wrote:
> > 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).
>
> Yes, that should
On Mon, 8 Jun 2015, John Stultz wrote:
> On Sat, Jun 6, 2015 at 2:44 AM, Thomas Gleixner 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 leav
On Sat, Jun 6, 2015 at 2:44 AM, Thomas Gleixner 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
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 tim
On Fri, Jun 5, 2015 at 7:12 AM, Richard Cochran
wrote:
> On Fri, Jun 05, 2015 at 11:10:08AM +0200, Peter Zijlstra wrote:
>> Firstly I would strongly suggest such applications not use UTC because
>> of this, I think TAI was invented for just this reason.
>
> So I wonder whether the bug in the origi
On Fri, Jun 5, 2015 at 12:29 AM, Peter Zijlstra wrote:
> On Thu, Jun 04, 2015 at 05:08:11PM -0700, John Stultz wrote:
>> I'm not sure how this follows. Leap smearing is a different behavior
>> and I'd like to support it (as a separate clockid) as well, but adding
>> that support doesn't change tha
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?
Another one: data loggers for scientific applications using UTC time
stamps.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Fri, Jun 05, 2015 at 11:10:08AM +0200, Peter Zijlstra wrote:
> Firstly I would strongly suggest such applications not use UTC because
> of this, I think TAI was invented for just this reason.
So I wonder whether the bug in the original post affects TAI timers as
well...
> Secondly, how would J
On Fri, 5 Jun 2015, Prarit Bhargava wrote:
>
>
> On 06/05/2015 05:04 AM, 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 sca
On 06/05/2015 05:04 AM, 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 milli
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
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 1
On Thu, Jun 04, 2015 at 05:08:11PM -0700, John Stultz wrote:
> I'm not sure how this follows. Leap smearing is a different behavior
> and I'd like to support it (as a separate clockid) as well, but adding
> that support doesn't change that the existing behavior applying the
> leapsecond to UTC/CLOC
On Wed, Jun 3, 2015 at 11:48 PM, Ingo Molnar wrote:
> * John Stultz wrote:
>>
>> 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 us
* John Stultz 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
On Wed, Jun 3, 2015 at 2:04 AM, Ingo Molnar wrote:
>
> * John Stultz wrote:
>
>> > Instead of having these super rare special events, how about implementing
>> > leap
>> > second smearing instead? That's far less radical and a lot easier to test
>> > as
>> > well, as it's a continuous mechanism
* John Stultz wrote:
> > Instead of having these super rare special events, how about implementing
> > leap
> > second smearing instead? That's far less radical and a lot easier to test
> > as
> > well, as it's a continuous mechanism. It will also confuse user-space a lot
> > less, because
On Tue, Jun 2, 2015 at 2:01 AM, Ingo Molnar wrote:
>
> * John Stultz wrote:
>
>> Currently, leapsecond adjustments are done at tick time.
>>
>> As a result, the leapsecond was applied at the first timer
>> tick *after* the leapsecond (~1-10ms late depending on HZ),
>> rather then exactly on the s
On Tue, Jun 2, 2015 at 2:21 AM, Peter Zijlstra wrote:
> On Tue, Jun 02, 2015 at 11:01:54AM +0200, Ingo Molnar wrote:
>> > Currently, leapsecond adjustments are done at tick time.
>> >
>> > As a result, the leapsecond was applied at the first timer
>> > tick *after* the leapsecond (~1-10ms late dep
On Tue, Jun 02, 2015 at 11:01:54AM +0200, Ingo Molnar wrote:
> > Currently, leapsecond adjustments are done at tick time.
> >
> > As a result, the leapsecond was applied at the first timer
> > tick *after* the leapsecond (~1-10ms late depending on HZ),
> > rather then exactly on the second edge.
* John Stultz wrote:
> Currently, leapsecond adjustments are done at tick time.
>
> As a result, the leapsecond was applied at the first timer
> tick *after* the leapsecond (~1-10ms late depending on HZ),
> rather then exactly on the second edge.
>
> This was in part historical from back when
On Fri, May 29, 2015 at 01:24:28PM -0700, John Stultz wrote:
> Apologies to Richard Cochran, who pushed for such a change
> years ago, which I resisted due to the concerns about the
> performance overhead.
For the record, I got the idea from Michel Hack of IBM.
> While I suspect this isn't extrem
22 matches
Mail list logo
