Linux's Multi-Grain Timestamps Short-Lived: Removed From The Kernel After A Few Weeks

[Sonadow]

There's some discussion on fsdevel about 100ns granularity 64bit time, to replace the separate sec/nsec format in use today. From here: https://lore.kernel.org/linux-fsdevel/CAHk-=whAwTJduUZTrsLFnj1creZMfO7eCNERHXZQmzX+qLqZMA@mai l.gmail.com/

Maybe the smarter thing to do is to just ask Christian how the Windows kernel does it, and then implement something similar yet slightly different.

[coder]

There's some discussion on fsdevel about 100ns granularity 64bit time, to replace the separate sec/nsec format in use today. From here: https://lore.kernel.org/linux-fsdevel/CAHk-=whAwTJduUZTrsLFnj1creZMfO7eCNERHXZQmzX+qLqZMA@mai l.gmail.com/

...
Now that 292 year range has become 29,247
years, and filesystem people *might* find the "year-31k" problem
acceptable.
...

LOL. I have no time for people who insist on solving the "year 2262" problem, today.

The thing I like about nanosecond timestamps is that it gives you the ability to do much finer-grained synchronization than 0.1 microsecond. If this is only concerning filesystem timestamps, then I'd agree that 0.1 microsecond might be okay, however I doubt these timestamps will stay limited to filesystems.

are there any timestamp-able Linux functions within the Linux OS that occur in a timeframe less than a tenth of a microsecond?

Within the kernel or using io_uring, sure!

If you're going to insist on including syscall overhead, then no. Not today, at least.