lkml.org 
[lkml]   [2016]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Date
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

\
 
 \ /
  Last update: 2016-11-18 23:54    [W:0.134 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site