On Mon, 19 Aug 2019, Arul Jeniston wrote: > hi Tglx, > > But for the above scenario: > > > > ktime_get() > > do { > > seq = read_seqcount_begin(&tk_core.seq); > > base = tk->tkr_mono.base; > > nsecs = timekeeping_get_ns(&tk->tkr_mono); > > > > } while (read_seqcount_retry(&tk_core.seq, seq)); > > > > So if the interrupt which updates the timekeeper hits in the middle of > > timekeeping_get_ns() then the result is discarded because the sequence > > count changed and read_seqcount_retry() returns true. So it takes another > > round which will be perfectly aligned with the updated time keeper. > > > > Do you mean to say the timekeeper updates always happen from ktime_get? > My point was, when one thread is in ktime_get other thread/isr updates > timekeeper from different flow. Timekeeper updates happen of course NOT from ktime_get(), but ktime_get() is protected against concurrent updates via the seqcount. Simplified without all the required barriers etc. ktime_get() do { seq = tk->seq; if (seq & 1) continue; base = tk->base; nsec = get_nsec(); while (seq != tk->seq); update() tk->seq++; update_data(); tk-<seq++; It does not matter whether the update is an interrupt on the same CPU which hits ktime_get() or whether it happens concurrent on a different CPU. ktime_get() can never use inconsistent tk data for calculating the time. Thanks, tglx