On Wed, May 23, 2018 at 4:33 AM, Miroslav Lichvar <[email protected]> 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.
Thanks for the patch! I feel like we tried this years back, but had to revert it. But its been awhile. Am I confusing things? > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > index 49cbceef5deb..6922dae7317c 100644 > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -2047,10 +2047,6 @@ void update_wall_time(void) > tk->tkr_mono.cycle_last, > tk->tkr_mono.mask); > #endif > > - /* Check if there's really nothing to do */ > - if (offset < real_tk->cycle_interval) > - goto out; > - Apologies again, as I don't have a lot of context here these days, but this could mean we end up doing unnecessary work on every update_wall_time, no? Would a "force" flag be better to pass to update_wall_time() to only avoid the short-cut in the non-adjtimex case? thanks -john
