On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon <[email protected]> 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 <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
