Messages in this thread | | | Subject | Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build | From | "James H. Cloos Jr." <> | Date | Fri, 02 Apr 2004 02:57:41 -0500 |
| |
>>>>> "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/
| |