On Wed, 2024-09-11 at 20:19 +0000, Arnd Bergmann wrote: > On Wed, Sep 11, 2024, at 19:55, John Stultz wrote: > > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > > > index 5391e4167d60..56b979471c6a 100644 > > > My confusion comes from the fact it seems like that would mean you > > have to do all your timestamping with CLOCK_MONOTONIC (so you have a > > useful floor value that you're keeping), so I'm not sure I understand > > the utility of returning CLOCK_REALTIME values. I guess I don't quite > > see the logic where the floor value is updated here, so I'm guessing. > > I think we could take this further and store the floor value > in the timekeeper itself rather than in a global variable > next to the caller. > > And instead of storing the absolute floor value, it would > be enough to store the delta since the previous > update_wall_time(), which in turn can get updated by a > variant of ktime_get_real_ts64() and reset to zero during > update_wall_time(). > > timespec64_add_ns() over the traditional version, and the > fine-grained version needs to atomically update that value. > If the delta value has to be a 64-bit integer, there also > needs to be some serialization of the reader side, but I > think that can be done with read_seqcount_begin() . > I think we'd have to track this delta as an atomic value and cmpxchg new values into place. The zeroing seems quite tricky to make race- free. Currently, we fetch the floor value early in the process and if it changes before we can swap a new one into place, we just take whatever the new value is (since it's just as good). Since these are monotonic values, any new value is still newer than the original one, so its fine. I'm not sure that still works if we're dealing with a delta that is siding upward and downward. Maybe it does though. I'll take a stab at this tomorrow and see how it looks. Thanks for the suggestion! -- Jeff Layton <jlayton@xxxxxxxxxx>
