Dave Chinner <david@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
