* [PATCHv1] timekeeping: Update multiplier when NTP frequency is set directly
@ 2018-05-29 10:53 Miroslav Lichvar
2018-05-29 17:42 ` John Stultz
0 siblings, 1 reply; 3+ messages in thread
From: Miroslav Lichvar @ 2018-05-29 10:53 UTC (permalink / raw)
To: linux-kernel
Cc: Miroslav Lichvar, Thomas Gleixner, John Stultz, Richard Cochran,
Prarit Bhargava
When the NTP frequency is set directly from userspace using the
ADJ_FREQUENCY or ADJ_TICK timex mode, immediately update the
timekeeper's multiplier instead of waiting for the next tick.
This removes a hidden non-deterministic delay in setting of the
frequency and allows an extremely tight control of the system clock
with update rates close to or even exceeding the kernel HZ.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
Notes:
RFC->v1:
- added a new parameter to force the update of the timekeeper to the current
NTP tick length only from adjtimex()
- added timekeeping_advance() to keep the parameter local to timekeeping.c
kernel/time/timekeeping.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 49cbceef5deb..5524c07d43e3 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2021,11 +2021,11 @@ static u64 logarithmic_accumulation(struct timekeeper *tk, u64 offset,
return offset;
}
-/**
- * update_wall_time - Uses the current clocksource to increment the wall time
- *
+/*
+ * timekeeping_advance - Updates the timekeeper to the current time and
+ * current NTP tick length
*/
-void update_wall_time(void)
+static void timekeeping_advance(bool force_update)
{
struct timekeeper *real_tk = &tk_core.timekeeper;
struct timekeeper *tk = &shadow_timekeeper;
@@ -2048,7 +2048,7 @@ void update_wall_time(void)
#endif
/* Check if there's really nothing to do */
- if (offset < real_tk->cycle_interval)
+ if (offset < real_tk->cycle_interval && !force_update)
goto out;
/* Do some additional sanity checking */
@@ -2105,6 +2105,15 @@ void update_wall_time(void)
clock_was_set_delayed();
}
+/**
+ * update_wall_time - Uses the current clocksource to increment the wall time
+ *
+ */
+void update_wall_time(void)
+{
+ timekeeping_advance(false);
+}
+
/**
* getboottime64 - Return the real time of system boot.
* @ts: pointer to the timespec64 to be set
@@ -2332,6 +2341,10 @@ int do_adjtimex(struct timex *txc)
write_seqcount_end(&tk_core.seq);
raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
+ /* Update the multiplier immediately if frequency was set directly */
+ if (txc->modes & (ADJ_FREQUENCY | ADJ_TICK))
+ timekeeping_advance(true);
+
if (tai != orig_tai)
clock_was_set();
--
2.14.3
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCHv1] timekeeping: Update multiplier when NTP frequency is set directly
2018-05-29 10:53 [PATCHv1] timekeeping: Update multiplier when NTP frequency is set directly Miroslav Lichvar
@ 2018-05-29 17:42 ` John Stultz
2018-06-04 10:17 ` Miroslav Lichvar
0 siblings, 1 reply; 3+ messages in thread
From: John Stultz @ 2018-05-29 17:42 UTC (permalink / raw)
To: Miroslav Lichvar; +Cc: lkml, Thomas Gleixner, Richard Cochran, Prarit Bhargava
On Tue, May 29, 2018 at 3:53 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> When the NTP frequency is set directly from userspace using the
> ADJ_FREQUENCY or ADJ_TICK timex mode, immediately update the
> timekeeper's multiplier instead of waiting for the next tick.
>
> This removes a hidden non-deterministic delay in setting of the
> frequency and allows an extremely tight control of the system clock
> with update rates close to or even exceeding the kernel HZ.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: Prarit Bhargava <prarit@redhat.com>
> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
> ---
>
> Notes:
> RFC->v1:
> - added a new parameter to force the update of the timekeeper to the current
> NTP tick length only from adjtimex()
> - added timekeeping_advance() to keep the parameter local to timekeeping.c
>
> kernel/time/timekeeping.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 49cbceef5deb..5524c07d43e3 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -2021,11 +2021,11 @@ static u64 logarithmic_accumulation(struct timekeeper *tk, u64 offset,
> return offset;
> }
>
> -/**
> - * update_wall_time - Uses the current clocksource to increment the wall time
> - *
> +/*
> + * timekeeping_advance - Updates the timekeeper to the current time and
> + * current NTP tick length
> */
> -void update_wall_time(void)
> +static void timekeeping_advance(bool force_update)
This is kind of a nit, but mind switching out bool for an enum? Using
something like TK_ADV_NORMAL and TK_ADV_FORCE?
> +void update_wall_time(void)
> +{
> + timekeeping_advance(false);
> +}
The enum makes usage like timekeeping_advance(false) a little less
opaque to the reader ("Wait, don't advance? Let me go look at the
function").
We got bitten by this earlier when we had the old
"timekeeping_update(tk, true, false, true)" usage.
thanks
-john
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCHv1] timekeeping: Update multiplier when NTP frequency is set directly
2018-05-29 17:42 ` John Stultz
@ 2018-06-04 10:17 ` Miroslav Lichvar
0 siblings, 0 replies; 3+ messages in thread
From: Miroslav Lichvar @ 2018-06-04 10:17 UTC (permalink / raw)
To: John Stultz; +Cc: lkml, Thomas Gleixner, Richard Cochran, Prarit Bhargava
On Tue, May 29, 2018 at 10:42:05AM -0700, John Stultz wrote:
> On Tue, May 29, 2018 at 3:53 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > -void update_wall_time(void)
> > +static void timekeeping_advance(bool force_update)
>
> This is kind of a nit, but mind switching out bool for an enum? Using
> something like TK_ADV_NORMAL and TK_ADV_FORCE?
>
> > +void update_wall_time(void)
> > +{
> > + timekeeping_advance(false);
> > +}
>
> The enum makes usage like timekeeping_advance(false) a little less
> opaque to the reader ("Wait, don't advance? Let me go look at the
> function").
>
> We got bitten by this earlier when we had the old
> "timekeeping_update(tk, true, false, true)" usage.
Ok. That make sense. I'll send a v2.
Thanks,
--
Miroslav Lichvar
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-06-04 10:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-29 10:53 [PATCHv1] timekeeping: Update multiplier when NTP frequency is set directly Miroslav Lichvar
2018-05-29 17:42 ` John Stultz
2018-06-04 10:17 ` Miroslav Lichvar
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).