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
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
