Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available | Date | Fri, 18 Nov 2016 22:54:02 +0000 |
| |
Dave Chinner <david@fromorbit.com> wrote:
> And when we start thinking in those timeframes, an > increase in timestamp resoultion of at least another 10e-3 is > likely....
Is it, though? To be useful, surely you have to be able to jam quite a few instructions into a 1ns block, including memory accesses.
Rather than providing:
struct timestamp { __s64 seconds; __s64 femtoseconds; };
which would require 64-bit divisions to get nanosecond timestamps that we do actually use, I would lean towards:
struct timestamp { __s64 seconds; __s32 nanoseconds; __s32 femtoseconds; };
where the fields are, in effect, additive. Which means I could represent this as:
__s64 stx_atime_s; /* Last access time */ __s64 stx_btime_s; /* File creation time */ __s64 stx_ctime_s; /* Last attribute change time */ __s64 stx_mtime_s; /* Last data modification time */ __s32 stx_atime_ns; /* Last access time (ns part) */ __s32 stx_btime_ns; /* File creation time (ns part) */ __s32 stx_ctime_ns; /* Last attribute change time (ns part) */ __s32 stx_mtime_ns; /* Last data modification time (ns part) */
and then add:
__s32 stx_atime_fs; /* Last access time (fs part) */ __s32 stx_btime_fs; /* File creation time (fs part) */ __s32 stx_ctime_fs; /* Last attribute change time (fs part) */ __s32 stx_mtime_fs; /* Last data modification time (fs part) */
later.
If we *really* do want to allow for atto- or femto- second resolution timestamps (and you've still not entirely convinced me that it's going to be necessary - the speed of signal propagation still has an ungetroundable limit), then we could stick the space in now - but I think it's likely to remain dead space.
Maybe we should switch to Windows-style timestamp resolution:
struct timestamp { __s64 hundred_ns; /* Time in 100ns increments */ __s32 femtoseconds; /* Additional fs component */ };
> > Using the existing FS_*_FL flags as initial values is not worse than > > starting with any other arbitrary values for the flags. > > Except it starts with a sparse set of flags for no good reason.
Actually, a very good reason. You can map those flags, on ext4 at least, with a load, an AND and an OR. Three instructions[*]. If the bits don't correspond, it gets more expensive (4-5 instructions per bit + 1).
[*] Leastways, it *should* be three instructions, but gcc fails to optimise it correctly. I have a bz logged for this.
David
| |