linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: John Stultz <john.stultz@linaro.org>
Cc: 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: Sun, 31 May 2015 18:05:39 +0200	[thread overview]
Message-ID: <20150531160539.GA2497@localhost.localdomain> (raw)
In-Reply-To: <1432931068-4980-5-git-send-email-john.stultz@linaro.org>

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 extremely critical, folks who
> care about strict leap-second correctness will likely
> want to watch this, and it will likely be a -stable candidate.

I think this is a step in the right direction.  If the 'next_leap_sec'
is made available to the vdso, then the 1-10 ms time error could also
be prevented there.

I have some comments, but, as is, feel free to add my ack.

Acked-by: Richard Cochran <richardcochran@gmail.com>

> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> index 472591e..6e15fbb 100644
> --- a/kernel/time/ntp.c
> +++ b/kernel/time/ntp.c

> @@ -359,6 +364,33 @@ u64 ntp_tick_length(void)
>  	return tick_length;
>  }
>  
> +/**
> + * get_leap_state - Returns the NTP leap state
> + * @next_leap_sec:	Next leapsecond in time64_t
> + * @next_leap_ktime:	Next leapsecond in ktime_t
> + *
> + * Provides NTP leapsecond state. Returns direction
> + * of the leapsecond adjustment as an integer.
> + */
> +int get_leap_state(time64_t *next_leap_sec, ktime_t *next_leap_ktime)
> +{
> +	int dir;
> +
> +	if ((time_state == TIME_INS) && (time_status & STA_INS)) {

This can be reduced to just one test on (time_state == TIME_INS).
If user spaces clears STA_INS, then you can immediately cancel the
leap second.

> +		dir = -1;
> +		*next_leap_sec = ntp_next_leap_sec;
> +		*next_leap_ktime = ktime_set(ntp_next_leap_sec, 0);
> +	} else if ((time_state == TIME_DEL) && (time_status & STA_DEL)) {
> +		dir = 1;
> +		*next_leap_sec = ntp_next_leap_sec;
> +		*next_leap_ktime = ktime_set(ntp_next_leap_sec, 0);
> +	} else {
> +		dir = 0;
> +		*next_leap_sec = TIME64_MAX;
> +		next_leap_ktime->tv64 = KTIME_MAX;
> +	}
> +	return dir;
> +}
>  
>  /*
>   * this routine handles the overflow of the microsecond field

> @@ -382,15 +414,21 @@ int second_overflow(unsigned long secs)
>  	 */
>  	switch (time_state) {
>  	case TIME_OK:
> -		if (time_status & STA_INS)
> +		if (time_status & STA_INS) {

The user sets STA_INS via adjtimex, but we don't change to TIME_INS
until the next tick.  Why not change immediately?  Then this funtion
would only need to check for TIME_INS && (secs % 86400 == 0)  and the
very unlikey TIME_DEL.

>  			time_state = TIME_INS;
> -		else if (time_status & STA_DEL)
> +			ntp_next_leap_sec = secs + SECS_PER_DAY -
> +						(secs % SECS_PER_DAY);
> +		} else if (time_status & STA_DEL) {
>  			time_state = TIME_DEL;
> +			ntp_next_leap_sec = secs + SECS_PER_DAY -
> +						 ((secs+1) % SECS_PER_DAY);
> +		}
>  		break;
>  	case TIME_INS:
> -		if (!(time_status & STA_INS))
> +		if (!(time_status & STA_INS)) {
> +			ntp_next_leap_sec = TIME64_MAX;
>  			time_state = TIME_OK;
> -		else if (secs % 86400 == 0) {
> +		} else if (secs % SECS_PER_DAY == 0) {
>  			leap = -1;
>  			time_state = TIME_OOP;
>  			printk_deferred(KERN_NOTICE

> @@ -711,6 +752,24 @@ int __do_adjtimex(struct timex *txc, struct timespec64 *ts, s32 *time_tai)
>  	if (!(time_status & STA_NANO))
>  		txc->time.tv_usec /= NSEC_PER_USEC;
>  
> +	/* Handle leapsec adjustments */

This block and its commnet rather confused me.  What this code
actually does is fix up the time value returned to the caller of
adjtimex, but only in the 1-10 millisecond window before the leap
second tick.

> +	if (unlikely(ts->tv_sec >= ntp_next_leap_sec)) {
> +		if ((time_state == TIME_INS) && (time_status & STA_INS)) {
> +			result = TIME_OOP;
> +			txc->tai++;
> +			txc->time.tv_sec--;
> +		}
> +		if ((time_state == TIME_DEL) && (time_status & STA_DEL)) {
> +			result = TIME_WAIT;
> +			txc->tai--;
> +			txc->time.tv_sec++;
> +		}
> +		if ((time_state == TIME_OOP) &&
> +					(ts->tv_sec == ntp_next_leap_sec)) {
> +			result = TIME_WAIT;
> +		}
> +	}
> +
>  	return result;
>  }

Thanks,
Richard

  reply	other threads:[~2015-05-31 16:05 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 [this message]
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
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=20150531160539.GA2497@localhost.localdomain \
    --to=richardcochran@gmail.com \
    --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@redhat.com \
    --cc=prarit@redhat.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).