On Thu, Sep 12, 2024, at 11:34, Jeff Layton wrote:
> On Thu, 2024-09-12 at 10:01 +0000, Arnd Bergmann wrote:
>> On Wed, Sep 11, 2024, at 20:43, Jeff Layton wrote:
>>
>> That way you avoid the atomic64_try_cmpxchg()
>> inode_set_ctime_current(), making that case faster,
>> and avoid all overhead in coarse_ctime() unless you
>> use both types during the same tick.
>>
>
> With the current code we only get a fine grained timestamp iff:
>
> 1/ the timestamps have been queried (a'la I_CTIME_QUERIED)
> 2/ the current coarse-grained or floor time would not show a change in
> the ctime
>
> If we do what you're suggesting above, as soon as one task sets the
> flag, anyone calling current_time() will end up getting a brand new
> fine-grained timestamp, even when the current floor time would have
> been fine.
Right, I forgot about this part of your work, the
I_CTIME_QUERIED logic definitely has to stay.
> That means a lot more calls into ktime_get_real_ts64(), at least until
> the timer ticks, and would probably mean a lot of extra journal
> transactions, since those timestamps would all be distinct from one
> another and would need to go to disk more often.
I guess some of that overhead would go away if we just treated
tk_xtime() as the floor value without an additional cache,
and did the comparison against inode->i_ctime inside of
a new ktime_get_real_ts64_newer_than(), but there is still the
case of a single inode getting updated a lot, and it would
break the ordering of updates between inodes.
Arnd
