On Thu, 2010-08-05 at 01:06 +0400, Alexander Gordeev wrote:
Hmm. So this brings up an interesting point. If the system is an one
which uses arch_gettimeoffset() (which means it doesn't have
clocksources), I'm not sure if this function would return what you'd
expect.
The issue is that jiffies is the basic clocksource that is in use on
these systems, but the arch_gettimeoffset() function returns an
inter-tick time value (usually by reading the interrupt generating
decrementer or whatnot). So in this case, you'd get a
CLOCK_MONOTONIC_RAW time that is based off the raw jiffies value at the
last tick, and CLOCK_REALTIME time value at the exact time of the call.
That offset between the two would then vary depending on when in the
inter-tick period the call was made.
The two solutions would be:
1) Add the arch_gettimeoffset() value to nsecs_raw as well. Should be
safe, as any freq variance from the raw freq will be limited to 1 tick
length and won't accumulate.
2) Don't add arch_gettimeoffset to either value, providing the raw and
real time values at the last tick.
I'd probably go with #1.
Otherwise, the code looks good.
thanks
-john
--