On Thu, 13 Nov 1997, Jonathan Stone wrote:

> >Has there been any consideration of sampling some sort of high resolution
> >timer at trap/context switch time instead of using a high resolution timer
> >interrupt for statistics gathering?  It could elimitate the splstatclock()
> >problems at the same time as improving overall timing accuracy.
> 
> 1) Not all systems have such a timer.    (sparcs do, but...)

Not all machines have a high resolution secondary timer interrupt either.
Most do have the ability to read a timer with greater resolution than they
can afford to take heavyweight (going all the way to C code) interrupts.

You can't control what's in older machines so they will need to do the
best they can.  However, most newer processors have cycle counters and
performance sampling registers so on those you should be able to achieve
accuracies approaching one machine cycle.

> 
> 2) that might work for process accouting and maybe user PC-sampling
>    (tho there are applications that synch to the sheduling clock, where
>    where you really want a different clock, if possible).
>
>    But  I don't understand how you would get *kernel* profiling
>    data via this technique.  Without that, how would we tune kernels?
>    (some ports do tune the MD kernel code).

For kernel profiling you still need to build a profiling kernel and add
code to function entry and exits, don't you?  That code could simply
sample the H/W profiling timer.  All profiling is intrusive, but this is
not much more intrusive than what currently needs to be done and has the
advantage of being able to profile code that runs at splhigh() or above.

=========================================================================
Eduardo Horvath				eeh@btr.com
"Cliffs are for climbing.  That's why God invented grappling hooks."
					- Benton Frasier