Re: [RFC][PATCH] linux-2.5.59_getcycles_A0

[john stultz <johnstul@us.ibm.com>]

On Fri, 2003-02-07 at 16:18, Andi Kleen wrote:
> Anyways my point stands - get_cycles should be only used when no
> wall time is needed, so I see no reason to complicate it and slow
> it down with external timers.

Because it (or some similar form) is needed. The hangcheck timer code
needs a method for reading a hard clock. 

I've talked it over with Joel and it became obvious that there was no
efficient and clean way to get do_gettimeofday to appropriately handle
the situation where we loose 60 seconds worth of ticks. Thus Joel needs
raw access to a hardware clock, so he used get_cycles() and
loops_per_jiffy to calculate a time interval. 

However this doesn't work on systems w/o a synced TSC, so by simply
making get_cycles() indirect to the TSC or cyclone implementation allows
it to do the right thing. It only minorly (extra pointer dereference and
call) affects non summit based boxes and returns (albeit slowly)
non-random values on summit based boxes. 

Now maybe if you'd really rather not change get_cycles, hangcheck_timer
could instead use a different interface to do the same indirection.
Would you have any gripes with that?

thanks for the feedback.
-john