On Tue, Jul 9, 2024, at 20:27, Jeff Layton wrote:
> 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:
>
>
> 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
I was thinking of keeping a name that is specific to the vfs
usage instead of the ktime_get_* namespace. I'm sure the timekeeping
maintainers will have an opinion on this though, one way or another.
> 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.
Why not update the cached value during the timekeeping update as well
instead of setting it to zero? That way you can just always use the
cached value for VFS and simplify the common code path for reading
that 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.
Right, or atomic64_cmpxchg() to make it work on 32-bit.
Arnd
