Re: oprofile and ARM A9 hardware counter

[stephane eranian <eranian@googlemail.com>]

On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 27, 2012 at 03:57:25PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon <will.deacon@arm.com> wrote:
>> >
>> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
>> > you may miss samples if they occur during critical kernel sections (and if
>> > you look at a profile, spin_unlock_irqrestore will be quite high).
>> >
>> But I am only running a user space noploop. So it spends 99% in user space, no
>> critical section.
>
> and your result is almost 99% of the way there :)
>
> There are also potential overheads from the PMU interrupts themselves, since
> there is a latency between overflow and taking the interrupt and then
> between there are actually reading the counter (they continue to count after
> overflow).
>
> That said, if you see any bugs in the code please do shout!
>
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts of interrupts (samples). I'll check on that this week-end.

>> > A7 and A15 have the ability to filter counters based on privilege level, so
>> > you can get more accurate userspace counts there.
>>
>> Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
>
> How do you handle that in libpfm4? On ARM, the event encodings remain the same,
> you just need to set some extra bits to determine which levels are included or
> excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
> event description).
>
It depends what you call the encoding? If the priv level can be encoded in the
attr->config field, then that's easy. If it needs to be set somewhere else, then
we need to figure out how you encode it in the attr struct. Either in some other
bits in attr->config or use attr->config1, for instance. You tell me.

> Will