RE: [PATCH/RFC v1 0/2] Human readable performance event description insysfs

From: Tomasz Fujak
Date: Wed Jan 20 2010 - 04:47:39 EST

> -----Original Message-----
> From: linux-arm-kernel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:linux-arm-
> kernel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Peter Zijlstra
> Sent: Wednesday, January 20, 2010 10:17 AM
> To: Tomasz Fujak
> Cc: jpihet@xxxxxxxxxx; p.osciak@xxxxxxxxxxx; jamie.iles@xxxxxxxxxxxx;
> will.deacon@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> kyungmin.park@xxxxxxxxxxx; mingo@xxxxxxx; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx; m.szyprowski@xxxxxxxxxxx
> Subject: Re: [PATCH/RFC v1 0/2] Human readable performance event
> description in sysfs
> On Wed, 2010-01-20 at 10:11 +0100, Tomasz Fujak wrote:
> > Hi,
> >
> > While I managed to build and run the early version (back from
> > December), I was unable to find the newest sources (infra + ARMv6,
> > ARMv7 support).
> > Where do I find them?
> >
> > The following patches provide a sysfs entry with hardware event human
> > readable description in the form of "0x%llx\t%lld-%lld\t%s\t%s" %
> > (event_value, minval, maxval, name, description) and means to
> populate
> > the file.
> > The version posted contains ARMv6, ARMv7 (Cortex-A[89]) support in
> > this matter.
> >
> > The intended use is twofold: for users to read the list directly and
> > for tools (like perf).
> >
> > This series includes:
> > [PATCH v1 1/2] perfevent: Add performance event structure definition
> > and 'extevents' sysfs entry
> > [PATCH v1 2/2] [ARM] perfevent: Event description list for ARMv6,
> > Cortex-A8 and Cortex-A9 exported
> Why do this in kernel space? Listing available events seems like
> something we can do from userspace just fine.

Sure we could, it's the other option. But it does not appeal to me. In case
of userspace tools (like the pref for which the above is meant) they'd need
to come with their own version of the list, which must match the host
platform. Right now the perf just forwards raw event number to the kernel
and that's it. Potentially it could bind a set of events supported to a
platform (how to detect which platform we execute on?). But how do we handle
different revisions and minor changes within a single platform?

That's why I think the kernel should expose supported events. At least with
an identifier suitable to unambiguously detect which HW defined event it is.

In the proposed approach I also provided a name a and description.
Right now if one wants to set a counter with some non-generic value, a
datasheet comes handy.
And Joe the average user does not necessarily know the detailed machine
he/she has, let alone the datasheet. With this approach the user is armed
with the event definition, which helps them go around outdated/unsupported

> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at