oprofile and ARM A9 hardware counter

[stephane eranian]

On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon <will.deacon at arm.com> wrote:
>> > 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.
>
> Ok, thanks. Keep in mind that you probably have variable rate clocks, which
> will affect the cycle counter frequency.
>
I assume it does not vary the clock if the workload is steady and just burning
cycles, e.g.: for(;;);

>> >> > 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.
>
> The way it's done with perf is to set the exclude{user,kernel,hv} fields in
> the attr. The ARM perf backend then translates these into the relevant bits
> which get orred into the config_base before hitting the hardware.
>
Well, that's also how we do it with libpfm4 on X86. This is because
with perf_events,
the exclude_* fields have priority over what you set in the attr->config field.

> Will