Messages in this thread | | | Date | Sun, 19 Jan 1997 14:36:21 -0500 | From | "David S. Miller" <> | Subject | Re: HZ=1000 & kernel profiling? |
| |
From: Paul Gortmaker <paul@rasty.anu.edu.au> Date: Sun, 19 Jan 1997 15:40:35 +1000 (EST)
(2) Use a sampling trigger that is comparable to 100Hz, but much more independent of general kernel activity than the timer interrupt, so that a functions execution time in relation to the timer interrupt will not effect the profiling data. In addition, you don't incurr the higher overhead of having an excessive timer interrupt rate as in (1).
Some more ideas, something tells me that if you run a seperate timer as you suggest, but make sure the profiling timer has the following two qualities:
1) The rate of the profiling timer tick is relatively prime to the rate of the normal tick
2) The profiling timer runs completely in assembler and does not save/restore state, just records the profiling info then returns from the trap, no c-code, smaller cache footprint and less cycles burned, thus the changed timing timing of the kernel caused by the profiling tick itself is reduced as much as possible
you'd get much more desirable and accurate results.
Just some ideas.
---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
| |