Daniel,

On Sat, Dec 23, 2006 at 07:53:47AM -0800, Daniel Walker wrote:
quoted text
> On Fri, 2006-12-22 at 02:43 -0800, Stephane Eranian wrote:
> > Hello,
> > 
> > 
> > The perfmon subsystems needs to compute per-CPU duration. It is using
> > sched_clock() to provide this information. However, it seems they are
> > big variations in the way sched_clock() is implemented for each architectures,
> > especially in the accuracy of the returned value (going from TSC to jiffies).
> > 
> 
> The vast majority of architectures return a scaled jiffies value for
> sched_clock(). MIPS, and ARM for instance are two, and i386 does
> sometimes. The function isn't very predictable in terms or what you'll
> get as output. 
> 
My understanding is that you'll get a per-CPU timestamp expressed in nanoseconds.
The granularity of the returned value is highly dependent on the CPU
architecture (and apparently on how you've compiled your kernel).

quoted text
> The most reliable way to get timing is to use gettimeofday() which in
> turn uses a lowlevel clock. I'm not sure exactly what your application
> is, but sometimes gettimeofday() can be a little complicated to use.
> Which is why I create the following clocksource changes,
> 
I do NOT need a wall-clock time. I am looking for a simple per-CPU clock
source with best possible granularity. I use the clock to compute elapsed
execution duration. I initially was using TSC, then during the code review
someone suggested I use sched_clock(). Using getttimeofday() can be failry
expensive and I need to compute the duration in the context switch path.

Now my understanding is that on some processors with frequence scaling,
using TSC may not easily allow computing elapsed time. So there may not
be any cheap solution to my problem.

quoted text
> ftp://source.mvista.com/pub/dwalker/clocksource/
> 
> the purpose of which is to allow generic access to suitable lowlevel
> clocks. It just extends the mechanism already used by gettimeofday(). 
> 

-- 

-Stephane
-
unsubscribe notice
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/