11.07 oprofile on panda busted?

Turgis, Frederic f-turgis at ti.com
Fri Sep 16 14:49:20 UTC 2011


Hi,

- To my understanding, oprofile is only a statistical tool based on regular sampling like "top" (well, I shall say /proc/stat). So it runs without impacting much your use case. I don't think it is triggered on system transitions. For that, I would use kernel traces or kprobes.
Still a very useful (and used) tool.

You choose oprofile to be triggered every X ms by timer or every "overflow" of 1 PMU counter. Of course, "overflow interrupt" issue kills use of PMU for triggering (but I found only 1 article in the past really leveraging that). When tool wakes-up, it reads ARM registers + any info allowing to state in which function, thread, kernel/userspace we are (requires also debug symbols)
By the way, ARM has a tool, which is an "oprofile" like where they tune wake-up timer and capture everything they can (kind of combination of top, oprofile, PMU counters reading... down to every ms). Not open source I think.

- PMU counter values are writable, no ? So if you want an interrupt every N events, you write "Overflow value - N" in counter and let counter run. On overflow interrupt, you reset counter to "Overflow value - N" again. With this "overflow interrupt" issue, this is clearly killing the use of it as an oprofile trigger.

Regards
Fred

 >>  Overflow is the only way of getting a counter interrupt right?  Then it's a fundamental problem for oprofile.
 CB> Yes, to my understanding, this is the only way. I'm not an OProfile expert and how it behaves internally. Here are my assumptions for the "not sure that this impacs OProfile"
CB> As I remember, counter is 32 bits, then interrupt should fire only at about 2 Billion cycles, meaning for a device running at 1GHz, after about 2s.
CB> OProfile is monitoring processes or functions durations. My high level view is that OProfile is looking at this profiling counter at "system transitions" like interrupts, context switches, ...
CB>Then this means that the monitored activity should be longer than 2s without being preempted by the system in order to face the issue. Is such a use-case realistic? or may be I missed stg

Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-dev/attachments/20110916/39c65750/attachment.html>


More information about the linaro-dev mailing list