Bug 13820 - timer.profile(NNN) variant using perf probes
Summary: timer.profile(NNN) variant using perf probes
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-08 01:33 UTC by Frank Ch. Eigler
Modified: 2015-12-02 21:30 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2012-03-08 01:33:34 UTC
It would be nice to have some syntactic sugar implemented in the
translator to present a profiling/backtrace-capable probe point
at arbitrary frequencies, and implement them in terms of 
perf.hw.cpu_cycles (unscaled variant if possible), related to
the cpu core speed and the script-requested Hz rate.
Comment 1 Frank Ch. Eigler 2012-03-08 01:48:28 UTC
e.g.

  probe timer.profile.hz(997) { }

could map on a 2000 MHz core to perf.hw.cpu_clock

  probe perf.type(0).config(0).sample(2006018) { }

(where 2006018 would be 2,000,000,000 / 997).
This would have to be calculated at module startup time.
And it may be that we'd actually need a more complicated
function, or even some sort of baby PLL, to approximate
the desired frequency.

It would probably be unwise to map timer.{hz,ms,etc.}(NNN)
to this because this uses up scarce resources, so can't be
unprivileged-safe.
Comment 2 Felix Lu 2015-12-02 21:30:54 UTC
Added a probe point timer.profile.freq.hz(N).

This is only accurate up to 100 hz.