lkml.org 
[lkml]   [2017]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Extreme time jitter with suspend/resume cycles
On Thu, 5 Oct 2017, Thomas Gleixner wrote:
> On Wed, 4 Oct 2017, John Stultz wrote:
> > So, on resume when we call __timekeeping_inject_sleeptime(), that uses
> > the TK_CLEAR_NTP which clears the NTP state (sets STA_UNSYNC, etc) .
> > I'm not sure how else we can notify userspace. It may be that ntpd
> > doesn't expect the kernel to set things as unsynced and doesn't
> > recover well, but the proper fix for that probably is in userspace.
>
> Errm. No, __timekeeping_inject_sleeptime() only updates the timekeeper.

That should read:

updates the timekeeper data fields, but does not call
timekeeping_update().

>
> We have two call sites:
>
> timekeeping_resume()
> {
> .....
> if (sleeptime_injected)
> __timekeeping_inject_sleeptime(tk, &ts_delta);
> ...
> timekeeping_update(tk, TK_MIRROR | TK_CLOCK_WAS_SET);
> ...
> }
>
> and
>
> timekeeping_inject_sleeptime64()
> {
> __timekeeping_inject_sleeptime(tk, &delta);
> ...
> timekeeping_update(tk, TK_CLEAR_NTP | TK_MIRROR | TK_CLOCK_WAS_SET);
> ...
> }
>
> But Gabriel talks about the effects from injecting sleep time in
> timekeeping_resume() because that's where we use
> read_persistent_clock64(). And there we don't clear NTP, unless there is
> some magic I'm missing completely.
>
> Thanks,
>
> tglx
>
>
>

\
 
 \ /
  Last update: 2017-10-05 16:12    [W:0.081 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site