On Tue, 2024-07-09 at 19:06 +0200, Arnd Bergmann wrote: > On Tue, Jul 9, 2024, at 17:27, Jeff Layton wrote: > > On Tue, 2024-07-09 at 17:07 +0200, Arnd Bergmann wrote: > > > On Tue, Jul 9, 2024, at 16:23, Jeff Layton wrote: > > > > The context for this is generally a write or other change to an > > inode, > > so I too am hoping the overhead won't be too bad. It does take > > great > > pains to avoid changing the ctime_floor value whenever possible. > > Ok, I see. Have you considered hooking directly into the code > in kernel/time/timekeeping.c then? > > Since the coarse time is backed by the timekeeper that itself > is a cache of the current time, this would potentially avoid > some duplication: > > - whenever the tk_core code gets updated, you can update > the ctime_floor along with it, or integrate ctime_floor > itself into the timekeeper > > - you can use the same sequence count logic, either with the > same &tk_core.seq or using a separate counter for the > ctime updates > Yes, I had considered it on an earlier draft, but my attempt was pretty laughable. You inspired me to take another look though... If we go that route, what I think we'd want to do is add a new floor value to the timekeeper and a couple of new functions: ktime_get_coarse_floor - fetch the max of current coarse time and floor ktime_get_fine_floor - fetch a fine-grained time and update the floor The variety of different offsets inside the existing timekeeper code is a bit bewildering, but I guess we'd want ktime_get_fine_floor to call timekeeping_get_ns(&tk->tkr_mono) and keep the latest return cached. When the coarse time is updated we'd zero out that cached floor value. Updating that value in ktime_get_fine_floor will require locking or (more likely) some sort of atomic op. timekeeping_get_ns returns u64 though, so I think we're still stuck needing to do a cmpxchg64. If there is a way to cut down what we'd need to track to 32-bits or less though, then that might become more appealing. -- Jeff Layton <jlayton@xxxxxxxxxx>
