lkml.org 
[lkml]   [2004]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
From
Date
>>>>> "Jamie" == Jamie Lokier <jamie@shareable.org> writes:

Jamie> When re-reading an inode, rounding the time up is done by
Jamie> setting the tv_nsec field to 999999999.

Jamie> If the on-disk timestamp is "now", i.e. the current second if
Jamie> it's a 1-second resolution, then we can avoid setting the
Jamie> timestamp to a future time by setting the tv_nsec field to the
Jamie> current wall time's nanosecond value. There is no need to
Jamie> round the time up any more than that.

Given how much time it will take to compare the file's timestamp to
current before choosing 999999999 or now for the tv_nsec field, is
it a reasonable shortcut to just always use now's nsec value?

Obviously it is not *that* many cycles to do the compare, but we are
talking about a nanoseconds field, and the current tv_sec could
increment during the compare....

-JimC

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.077 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site