On Fri, 15 Nov 2002, Jamie Lokier wrote:
>
> Once you're talking about nanoseconds, you can have both: each time
> you store an mtime, make sure the value is at least 1 nanosecond
> greater than the previously stored mtime for any file in the
> serialisation domain. If it is not, simply _wait_ for up to a
> nanosecond until the value has advanced enough.
Note that the fields already _are_ nanoseconds, it's just not updated at a
nanosecond rate. We're updating xtime only at a rate of HZ, where the 1 ms
comes from in 2.5.x.
And doing a full "gettimeofday()" sounds just a bit too expensive for the
stuff that needs to just update an inode time field.
But the thing is, we don't actually care about the exact time, we only
care about it being monotonically increasing, so I suspect we could just
have something like
static unsigned long xtime_count;
static struct timespec current_time(void)
{
struct timespec val;
unsigned long extra;
read_lock_irq(&xtime_lock);
val = xtime;
extra = xtime_count;
xtime_count = extra+1;
read_unlock_irq(&xtime_lock);
val.nsec += count;
if (val.tv_nsec > 1000000000) {
val.tv_nsec -= 1000000000;
val.tv_sec ++;
}
return val;
}
and then have the timer clear "xtime_count" every time it updates it.
This obviously doesn't give us nanosecond resolution, but it _does_ give
us "unique" timestamps (assuming a system call takes longer than a
nanosecond, which is likely true for the next decade or so - after that we
can start worrying about whether the users might be outrunning the clock).
Linus
-
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/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:35 EST