CONFIG_SLOW_TIMESTAMPS was Re: ANNOUNCE: CE Linux Forum -Specification V1.0 draft

[Andi Kleen]

Theodore Ts'o <tytso@xxxxxxx> writes:
>
> B) When CONFIG_FAST_TIMESTAMPS is enabled, the kernel SHALL provide
> the following 2 routines:
>
>       2.1 void store_timestamp(timestamp_t *t)

sched_clock() already exists and does that, although it is a bit confusingly
named. 

Or just use do_gettimeofday() which should be fast - it is used
in networking after all.

>       2.2 void timestamp_to_timeval(timestamp_t *t, struct timeval *tv) 

I don't think this API is a good idea. 

The obvious way to implement timestamp_t is just store the CPU integrated
time stamp counter into it (TSC in x86 terminology). But there are CPUs
where the TSC frequency changes when the CPU changes its core frequency
for power saving purposes.

(newer designs generally avoid this problem, but older designs often have 
it). Now to convert the TSC value you need the xtime and the TSC value
when the xtime matching the TSC value and you need to know about
all frequency changes that happened inbetween, so that you can 
compute the TSC offset. 

do_gettimeofday can handle this in a atomic matter, the CPU frequency
changes just has to resync xtime (I am not sure it does this currently,
but the API allows it at least) 

But splitting it into two functions like in your spec makes this
impossible, because you would need to keep track about all the
possible frequency changes in the timestamp_t between the store and
the timestamp_to_timeval to compute the TSC offset, which is obviously
not practical.

Anyways, the only way to avoid this problem would be to not use the
CPU TSC, but some external timer that is independent of the CPU
frequency (this is sometimes already done to work around other
problems). The problem is just that such external timers in the
southbridge are usually factor 100 and more slower than an TSC access
that can stay inside the CPU, because an access first has to cross the
slow CPU front side bus.

This would turn your fast time stamp into an extremly slow time stamp.

You would be probably better of by just using do_gettimeofday(), which
actually has a chance to use the TSC sanely and is not really that
slow usually.

BTW there are other problems on multiprocessor systems with this that
I don't want to go into.

-Andi

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