On Sat, 2024-06-29 at 03:33 +0200, Bruno Haible wrote: > Jeff Layton wrote: > > Failure of the test-stat-time test is what triggered us to revert the > > multigrain timestamp series from the Linux kernel last October. With > > that failure, we'd sometimes see timestamps showing files being modified > > in reverse order (if one got a fine-grained and another got a > > coarse-grained timestamp). > > I remember. Thanks for having listened to Jan Kara, Paul, me, and others. > > > Switch this code over to use file creation of two files to gauge the > > delay. Since that is operating on two different files, it should still > > be possible to gauge the coarse-grained timer tick from that. > > So, if I understand it right, there will now be two concepts of "file > system time stamp resolution": > a. regarding writes in a file, > b. regarding file creation, > and a <= b. Your patch to make nap() return b, not a, seems reasonable. > > Let's apply it when the copyright assignment process is complete. >
It's a little more subtle than that: When watching for changes on a single file (via stat() and the like), we ensure that timestamps are distinct so that ctime changes are visible to userland. When a file timestamps are not being observed, then we use the traditional coarse-grained timestamps that you're used to, but that's now subject to a floor value that represents that latest fine-grained stamp handed out. That's why creating two files and checking their timestamps afterward is still a viable method to gauge the coarse-grained timer tick length. These are new files that have never been observed before, so they end up being stamped with the current coarse grained clock value. -- Jeff Layton <jlay...@kernel.org>
