Re: [jlayton:mgtime 5/13] inode.c:undefined reference to `__invalid_cmpxchg_size'

[Jeff Layton <jlayton@kernel.org>]

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@kernel.org>