Re: Does oprofile suffer from aliasing?

Hi,

oprofile can operate basically in two different modes. The main approach
is to use hardware PMU. This should be used whenever possible. When
using PMU, the sampling is driven by the hardware itself (CPU). CPU
usually have some counters and a set of events which can be mapped to
various counters. When an event is triggered, the counter register is
increased. Then one sample is generated for each X-th event, where X can
be 10,000 for example. So it means that when some event is triggered
175,000,000 times, you'll get circa 17,500 samples. The X number differs
for various events in order to prevent overhead during collecting
samples.

--> PMU can be used with both operf and opcontrol.

In case PMU cannot be used (your CPU is not supported by oprofile OR
your CPU doesn't have PMU support OR your kernel is too old OR you're
using some virtualization without support of PMU etc), there's a
fallback mode (TIMER). When the timer mode is used, the interrupts are
generated by software and it works pretty much like you described.

--> The TIMER mode is available only for opcontrol (oprofile < 1.0).

tool/mode | PMU | TIMER 
----------+-----+--------
opcontrol | yes | yes
operf     | yes | no

There is another problem, that opcontrol AFAIK is not supported on ARM
architecture, so you could be able to use operf tool only.

--> I recommend using kernel new enough to support PMU (it should be at
least 2.6.32, but various CPU models have been added later), so the
latest possible kernel would be ideal.

--> Then I recommend using oprofile-1.0, tool operf with some hardware
PMU event (the default should be enough).

Hope it helps.

Regards,
Michael


On Wed, 2015-04-29 at 16:27 +0000, Grant Edwards wrote:
> I'm looking for a way to determine what processes/threads are using up
> the most CPU time on an ARM926 system.  We're running out of cycles
> and want to know where to concentrate optimization efforts.  The
> platform is currently running 2.6.22, but I could switch to a later
> kernel if it would buy me some useful profiling data.
> 
> The values printed by 'top' are meaningless due to aliasing.  
> 
> Most of the relevent threads are triggered by timers on fixed cycles
> and run for much less than one kernel tick. If I run a simple test
> with a thread that does a some work every 10ms, and top is using 10ms
> samples, then depending on the phase between the two 100Hz cycles, top
> may think the thread is using 0% or 100% (or sometimes fairly random
> values in between).
> 
> The documentation I've read on oprofile also refers to sampling,
> though I can't find a description of how that sampling is done.  If
> the sampling is random enough compared to the kernel timers, then it
> might work.
> 
> Is oprofile going to produce useful data for the case where threads
> are triggered on fixed cycles by timers?
> 
> If not, can anybody suggest anything else?
> 



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y