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@xxxxxxx> 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.
> >> > 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.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
