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>
