linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Richard Cochran <richardcochran@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>,
	Ingo Molnar <mingo@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Prarit Bhargava <prarit@redhat.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Jan Kara <jack@suse.cz>, Jiri Bohac <jbohac@suse.cz>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths
Date: Fri, 05 Jun 2015 11:10:08 +0200	[thread overview]
Message-ID: <1433495408.1495.8.camel@twins> (raw)
In-Reply-To: <20150605090433.GC1528@localhost.localdomain>

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.

  reply	other threads:[~2015-06-05  9:10 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29 20:24 [RFC][PATCH 0/4] Fixes for leapsecond expiring early ABS_TIME CLOCK_REALTIME timers John Stultz
2015-05-29 20:24 ` [RFC][PATCH 1/4] selftests: timers: Add leap-second timer edge testing to leap-a-day.c John Stultz
2015-05-29 20:24 ` [RFC][PATCH 2/4] timer_list: Add the base offset so remaining nsecs are accurate for non monotonic timers John Stultz
2015-05-29 20:24 ` [RFC][PATCH 3/4] ntp: Use printk_deferred in leapsecond path John Stultz
2015-06-02 10:31   ` Jiri Bohac
2015-06-02 10:43     ` Jiri Kosina
2015-06-02 16:14       ` John Stultz
2015-06-02 16:04     ` John Stultz
2015-05-29 20:24 ` [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths John Stultz
2015-05-31 16:05   ` Richard Cochran
2015-06-02  9:01   ` Ingo Molnar
2015-06-02  9:21     ` Peter Zijlstra
2015-06-02 14:09       ` John Stultz
2015-06-02 15:52     ` John Stultz
2015-06-03  9:04       ` Ingo Molnar
2015-06-03 17:44         ` John Stultz
2015-06-04  6:48           ` Ingo Molnar
2015-06-05  0:08             ` John Stultz
2015-06-05  7:29               ` Peter Zijlstra
2015-06-05  9:04                 ` Richard Cochran
2015-06-05  9:10                   ` Peter Zijlstra [this message]
2015-06-05 14:12                     ` Richard Cochran
2015-06-05 17:28                       ` John Stultz
2015-06-06  9:44                     ` Thomas Gleixner
2015-06-08 17:55                       ` John Stultz
2015-06-08 19:05                         ` Thomas Gleixner
2015-06-08 20:02                           ` Thomas Gleixner
2015-06-05 11:37                   ` Prarit Bhargava
2015-06-05 12:07                     ` Thomas Gleixner
2015-06-05 14:22                 ` Richard Cochran
2015-06-05 17:24                 ` John Stultz
2015-05-31 13:55 ` [RFC][PATCH 0/4] Fixes for leapsecond expiring early ABS_TIME CLOCK_REALTIME timers Prarit Bhargava
2015-06-01 11:57 ` Prarit Bhargava
2015-06-01 17:02   ` John Stultz
2015-06-01 17:43     ` Prarit Bhargava
2015-06-01 20:18 ` Daniel Bristot de Oliveira
2015-06-01 20:32   ` John Stultz
2015-06-01 21:42   ` Prarit Bhargava
2015-06-01 22:29     ` Daniel Bristot de Oliveira
2015-06-02  6:19       ` John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1433495408.1495.8.camel@twins \
    --to=peterz@infradead.org \
    --cc=bristot@redhat.com \
    --cc=jack@suse.cz \
    --cc=jbohac@suse.cz \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=prarit@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=shuahkh@osg.samsung.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).