[very cool RTC driven profiler description ...]
> I found that the data collected at low rates (e.g. RTC at 128Hz) was
> in agreement with that collected with the RTC at higher rates
> (e.g 2048Hz and above) and hence there was no need for a high rate
> so long as the sampling trigger was (reasonably) independent of
> general kernel activity. Furthermore, the data appeared reasonable,
> whereas the data obtained from using the timer IRQ @ 100Hz was
> clearly in error, and also inconsistent from one run to the next.
> (FWIW, I was profiling ethercard drivers at the time.)
as a (trivial) sidenote: higher sampling rates are useful if someone wants
to spend less time gathering sampling information :)
another thing ... this problem could be solved by simply defining two HZ
versions: HZ_TIMER and HZ_PROFILER. So instead of the current:
---{sched.c}-------------------------------------------------------->
if (prof_buffer && current->pid) {
extern int _stext;
unsigned long ip = instruction_pointer(regs);
ip -= (unsigned long) &_stext;
ip >>= prof_shift;
if (ip < prof_len)
prof_buffer[ip]++;
}
<--------------------------------------------------------------------
we could do:
---{sched.c}-------------------------------------------------------->
if (prof_buffer && current->pid &&
=========> !(jiffies%(HZ_PROFILER/HZ_TIMER)) ) {
extern int _stext;
unsigned long ip = instruction_pointer(regs);
ip -= (unsigned long) &_stext;
ip >>= prof_shift;
if (ip < prof_len)
prof_buffer[ip]++;
=========> clear_bit(TIMER_BH, &bh_active);
=========> return;
}
<--------------------------------------------------------------------
[the above solution is too naive, but you get the point]
The profiling and the timer irq are still not totally independent of each
other this way, but maybe already this solution is good enough, and it has
the additional benefit of being >highly< platform independent.
-- mingo