Profiling in Beagle Board

[vinay]

hi,

As I want to see the Profiling information of a program while running
in Board, so how can I measure this.

[Frans Meulenbroeks]

2009/5/14 vinay <vina...@gmail.com>:

>
> hi,
>
> As I want to see the Profiling information of a program while running
> in Board, so how can I measure this.

port gprof?

[Måns Rullgård]

Frans Meulenbroeks <fransmeu...@gmail.com> writes:

oprofile is much better.

--
Måns Rullgård
ma...@mansr.com

[Laurent Desnogues]

2009/5/14 Måns Rullgård <ma...@mansr.com>:

>>
>> port gprof?
>
> oprofile is much better.

Does it work now? Has Siarhei patch to workaround an errata been
accepted (or even proposed :)?

Laurent

[Siarhei Siamashka]

On Thu, May 14, 2009 at 2:27 PM, Laurent Desnogues wrote:
> 2009/5/14 Måns Rullgård:

>>>
>>> port gprof?
>>
>> oprofile is much better.
>
> Does it work now?

Yes, for those who know how to use it :) And at the very least, it
works reliably in a standard timer mode.

> Has Siarhei patch to workaround an errata been accepted (or even proposed :)?

There are several possible ways to improve oprofile usability on beagleboard.

One of them is to use a timer with much better samples commection
frequency than the 'standard' one. This can be accomplished either by
- using one of GPTIMER's (there are plenty of them in OMAP) for that,
it is simple, low overhead and robust.
- using generic high resolution timer framework from linux kernel,
that's probably a right solution from the architecture point of view,
but it has no practical advantages over GPTIMER one

Another solution is to workaround Cortex-A8 PMU errata and still use
performance monitoring counters. Experimental patch for that was
posted in this mailing list (not to linux-omap yet), but honestly I
did not get any kind of feedback regarding it at all. And more
importantly, I find myself to be quite satisfied with the GPTIMER
based driver :)

I generally prefer practical solutions which actually work and are
used by people, this gives a bit more confidence when submitting
patches :) If there is enough interest in having usable oprofile for
beagleboard and OMAP3 based boards/devices, the problem will get
solved itself and all the patches will reach mainline kernel
eventually.

The first step to improve the current situation would be to submit a
patch to add a kernel config option to disable broken ARMv7 PMU based
driver so that at least it does not override the standard timer
unconditionally.

[Måns Rullgård]

Siarhei Siamashka <siarhei....@gmail.com> writes:

> On Thu, May 14, 2009 at 2:27 PM, Laurent Desnogues wrote:
>> 2009/5/14 Måns Rullgård:
>>>>
>>>> port gprof?
>>>
>>> oprofile is much better.
>>
>> Does it work now?
>
> Yes, for those who know how to use it :) And at the very least, it
> works reliably in a standard timer mode.

I've never had any serious problems using oprofile. Very
occasionally, few or no samples will be collected in a run. In those
cases, I simply re-run the test.

--
Måns Rullgård
ma...@mansr.com

[Philip Balister]

On Thu, May 14, 2009 at 8:06 AM, Siarhei Siamashka
<siarhei....@gmail.com> wrote:
>
> Another solution is to workaround Cortex-A8 PMU errata and still use
> performance monitoring counters. Experimental patch for that was
> posted in this mailing list (not to linux-omap yet), but honestly I
> did not get any kind of feedback regarding it at all. And more
> importantly, I find myself to be quite satisfied with the GPTIMER
> based driver :)

You should try submitting it to linux-omap, this list is mostly users
and not kernel people. You may get more responses on the kernel
specific list.

Philip