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

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

On Fri, 2003-02-07 at 18:29, Andi Kleen wrote:
> On Fri, Feb 07, 2003 at 06:14:43PM -0800, john stultz wrote:
> > I'm not sure I understand your resistance to using an alternate clock
> > for get_cycles(). Could you better explain your problem with it?
> 
> I want to keep get_cycles() as a very fast primitive useful for benchmarking
> etc. and the random device. Accessing the southbridge would make it magnitudes 
> slower.

Ok, fair enough. But maybe a comment needs to be added to the get_cycles
to notify folks of the issues that surround it on systems without a
synced TSC?

> Regarding the watchdog: what it basically wants is a POSIX
> CLOCK_MONOTONIC clock. This isn't currently implemented by Linux, 
> but I expect it will be eventually because it's really useful for a lot
> of applications who just need an increasing time stamp in user space,
> and who do not want to fight ntpd for this. One example for such 
> an application is the X server who needs this for its internal 
> event sequencing.
> 
> Implementing it based on the current time infrastructure is very easy -
> you just do not add xtime and wall jiffies in, but only jiffies.

Actually, we can't do this, because if interrupts are being blocked
jiffies won't change. That is why I'm trying to provide hardware clock
access to hangcheck. It just so happened it was using get_cycles() as an
interface and it seemed appropriate for moving to timer_ops.

> I don't think doing any special hacks and complicating get_cycles()
> for it is the right way. Just implement a new monotonic clock primitive
> (and eventually export it to user space too) 

Ok, so you're telling me to use another interface. I'm down with that
(sometimes I just need it spelled out). Name suggestions? 
read_hw_timer?

thanks
-john