[PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
in [Kernel]
|
From: Corey Ashford on 4 Mar 2010 13:40 On 3/3/2010 6:30 PM, Corey Ashford wrote: > For your review, this patch adds support for arch-dependent symbolic > event names to the "perf stat" tool, and could be expanded to other > "perf *" commands fairly easily, I suspect. > > To support arch-dependent event names without adding arch-dependent code > to perf, I added a callout mechanism whereby perf will look for the > environment variable: PERF_ARCH_DEP_LIB, and if it exists, it will try > to open it as a shared object. If that succeeds, it looks for the symbol > "parse_arch_dep_event". If that exists, that function will be called by > parse_events() before all of the other event parsing functions in > parse-events.c. It is passed the same arguments as the other > parse_*_event functions, namely the event string and a pointer to an > event attribute structure. > > As the code existed, "perf stat" would print out the count results, but > for raw events (which is how arch-dependent events are supported in > perf_events), it would just print out a raw code. This is not > acceptable, especially when a symbolic name was placed on the command > line. So I changed the code to save away the event name that was passed > on the command line, rather than doing a reverse translation to an event > string based on the event type and config fields of the attr structure. > In this way, there's no need for a reverse translation function in the > arch-dependent library; only a event string->attr struct function is > needed. > > I could well be missing something, but I don't understand why reverse > translation is ever needed in perf, as long as the tool keeps track of > the original event strings. A couple of follow-up comments on this patch: This functionality was designed to provide a generalized interface to an external event name -> attr struct library, such as libpfm4. libpfm4 has an interface that nearly exactly matches parse_*_event() profiles, so it's quite easy to write a small wrapper function to call libpfm4's function. Ingo Molnar discussed adding some visibility to the arch-dependent event names through some other interface, such as through /sys/devices/pmus perhaps, but that discussion is a long way (as far as I know) from having something usable today. So you could think of this external library approach to be a stop-gap until something better is developed. When/if that new event naming mechanism becomes available, we can easily remove this external library support from perf. -- Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 cjashfor(a)us.ibm.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Corey Ashford on 5 Mar 2010 12:50 (I posted this yesterday, but I think LKML rejected it because there was more quoted text than my text. So I am reposting with no quoted text). A couple of follow-up comments on this patch: This functionality was designed to provide a generalized interface to an external event name -> attr struct library, such as libpfm4. libpfm4 has an interface that nearly exactly matches parse_*_event() profiles, so it's quite easy to write a small wrapper function to call libpfm4's function. Ingo Molnar discussed adding some visibility to the arch-dependent event names through some other interface, such as through /sys/devices/pmus perhaps, but that discussion is a long way (as far as I know) from having something usable today. So you could think of this external library approach to be a stop-gap until something better is developed. When/if that new event naming mechanism becomes available, we can easily remove this external library support from perf. -- Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR cjashfor(a)us.ibm.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 11 Mar 2010 07:50 * Corey Ashford <cjashfor(a)linux.vnet.ibm.com> wrote: > On 3/3/2010 6:30 PM, Corey Ashford wrote: > >For your review, this patch adds support for arch-dependent symbolic > >event names to the "perf stat" tool, and could be expanded to other > >"perf *" commands fairly easily, I suspect. > > > >To support arch-dependent event names without adding arch-dependent code > >to perf, I added a callout mechanism whereby perf will look for the > >environment variable: PERF_ARCH_DEP_LIB, and if it exists, it will try > >to open it as a shared object. If that succeeds, it looks for the symbol > >"parse_arch_dep_event". If that exists, that function will be called by > >parse_events() before all of the other event parsing functions in > >parse-events.c. It is passed the same arguments as the other > >parse_*_event functions, namely the event string and a pointer to an > >event attribute structure. > > > >As the code existed, "perf stat" would print out the count results, but > >for raw events (which is how arch-dependent events are supported in > >perf_events), it would just print out a raw code. This is not > >acceptable, especially when a symbolic name was placed on the command > >line. So I changed the code to save away the event name that was passed > >on the command line, rather than doing a reverse translation to an event > >string based on the event type and config fields of the attr structure. > >In this way, there's no need for a reverse translation function in the > >arch-dependent library; only a event string->attr struct function is > >needed. > > > >I could well be missing something, but I don't understand why reverse > >translation is ever needed in perf, as long as the tool keeps track of > >the original event strings. > > A couple of follow-up comments on this patch: > > This functionality was designed to provide a generalized interface to an > external event name -> attr struct library, such as libpfm4. libpfm4 has an > interface that nearly exactly matches parse_*_event() profiles, so it's > quite easy to write a small wrapper function to call libpfm4's function. > > Ingo Molnar discussed adding some visibility to the arch-dependent event > names through some other interface, such as through /sys/devices/pmus > perhaps, but that discussion is a long way (as far as I know) from having > something usable today. So you could think of this external library > approach to be a stop-gap until something better is developed. When/if that > new event naming mechanism becomes available, we can easily remove this > external library support from perf. I'm quite much against stop-gap measures like this - they tend to become tomorrow's impossible-to-remove quirk. If you want extensible events you can already do it by providing an ftrace tracepoint event via TRACE_EVENT. They are easy to add and ad-hoc, and are supported throughout by perf. That could be librarized further by providing an /eventfs or /proc/events interface to enumerate them. Or if you want to extend the perf events namespace ABI you can send patches for that as well. (It's not a big issue if a particular event is currently only supported on Power for example - as long as you make a good effort naming and structuring it in a reasonably generic way.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Corey Ashford on 11 Mar 2010 13:50 On 3/11/2010 4:46 AM, Ingo Molnar wrote: [snip] > If you want extensible events you can already do it by providing an ftrace > tracepoint event via TRACE_EVENT. They are easy to add and ad-hoc, and are > supported throughout by perf. Is TRACE_EVENT an appropriate way to add hardware-specific counter events? I will look into this. Thanks for the pointer. > > That could be librarized further by providing an /eventfs or /proc/events > interface to enumerate them. We can enumerate events this way, but there are other aspects to events than just their names (see below). > > Or if you want to extend the perf events namespace ABI you can send patches > for that as well. (It's not a big issue if a particular event is currently > only supported on Power for example - as long as you make a good effort naming > and structuring it in a reasonably generic way.) I'm not sure how that would work. The issue I am trying to solve here is that Power arch chips have a large number of very hardware-specific events that are not generalizable. Many of these events not only have names, but other user-configurable bits as well that select or narrow the scope of which exact events are recorded. This issue is dealt with nicely in libpfm4, as it has mechanisms for parsing event names and attributes (aka modifiers or unit masks), and then produces a usable config field for the perf_events_attr struct. Should I take it from the above that you are completely against the idea of using an external library for hardware-specific event and attribute naming? -- Regards, - Corey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 11 Mar 2010 14:20 * Corey Ashford <cjashfor(a)linux.vnet.ibm.com> wrote: > On 3/11/2010 4:46 AM, Ingo Molnar wrote: > [snip] > >If you want extensible events you can already do it by providing an ftrace > >tracepoint event via TRACE_EVENT. They are easy to add and ad-hoc, and are > >supported throughout by perf. > > Is TRACE_EVENT an appropriate way to add hardware-specific counter > events? I will look into this. Thanks for the pointer. > > > > >That could be librarized further by providing an /eventfs or /proc/events > >interface to enumerate them. > > We can enumerate events this way, but there are other aspects to > events than just their names (see below). > > > > >Or if you want to extend the perf events namespace ABI you can send patches > >for that as well. (It's not a big issue if a particular event is currently > >only supported on Power for example - as long as you make a good effort naming > >and structuring it in a reasonably generic way.) > > I'm not sure how that would work. The issue I am trying to solve > here is that Power arch chips have a large number of very > hardware-specific events that are not generalizable. Many of these > events not only have names, but other user-configurable bits as well > that select or narrow the scope of which exact events are recorded. > This issue is dealt with nicely in libpfm4, as it has mechanisms for > parsing event names and attributes (aka modifiers or unit masks), > and then produces a usable config field for the perf_events_attr > struct. > > Should I take it from the above that you are completely against the > idea of using an external library for hardware-specific event and > attribute naming? Could you give a few relevant examples of events in question, and the kind of configurability/attributes they have on Power? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Next
|
Last
Pages: 1 2 3 Prev: drm request 3 Next: xen: Make event channel work with PV extension of HVM |