perf: export tracepoint events via sysfs: iwlwifi and iwlwifi_io
in [Kernel]
|
Prev: [RFC][PATCH v1 01/15] perf: core, add functions to export events via sysfs
Next: perf: export tracepoint events via sysfs: mac80211
From: Steven Rostedt on 22 Jul 2010 22:20 On Fri, 2010-07-23 at 11:37 +1000, Dave Chinner wrote: > On Thu, Jul 22, 2010 at 09:54:04AM -0400, Steven Rostedt wrote: > > On Thu, 2010-07-22 at 15:48 +0200, Ingo Molnar wrote: > > > * Steven Rostedt <rostedt(a)goodmis.org> wrote: > > > > > Yeah - and the point of this submission is to allow the discussion of how to > > > achieve these registrations. > > > > > > Driver authors will want to have some control - for example the place where > > > the events directory shows up in sysfs within the driver's directory structure > > > - etc. > > > > > > But we indeed want to automate it as much as possible. > > > > Perhaps we can create a TRACE_EVENT_PATH() macro, that allows the > > developer to specify the path that the event will be seen in sysfs? > > Perhaps you could build that into the event class definition as well > so each separate class in a subsystem can be placed in it's own > sub-directory? > > That would make turning on and off specific classes trace points so > much simpler than it now, espcially for XFS where we now have > 250 > tracepoints that are mostly defined by event classes already... I was working on creating a "TRACE_CATEGORY()" that allowed you to put tracepoints into categories. Thus, these tracepoints will all still be in the XFS system, but you can add hierarchical categories that let you group and enable tracepoints in these groups. But I stopped this work since it was more ftrace specific than perf, and I need to figure out how to continue my work on ftrace and at the same time merge it towards perf. This has been taking much longer than I have expected. Perhaps I should just finish that work, and then see how we can make perf work with it too? -- Steve -- 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: Lin Ming on 22 Jul 2010 22:50 On Fri, 2010-07-23 at 10:14 +0800, Steven Rostedt wrote: > On Fri, 2010-07-23 at 11:37 +1000, Dave Chinner wrote: > > On Thu, Jul 22, 2010 at 09:54:04AM -0400, Steven Rostedt wrote: > > > On Thu, 2010-07-22 at 15:48 +0200, Ingo Molnar wrote: > > > > * Steven Rostedt <rostedt(a)goodmis.org> wrote: > > > > > > > Yeah - and the point of this submission is to allow the discussion of how to > > > > achieve these registrations. > > > > > > > > Driver authors will want to have some control - for example the place where > > > > the events directory shows up in sysfs within the driver's directory structure > > > > - etc. > > > > > > > > But we indeed want to automate it as much as possible. > > > > > > Perhaps we can create a TRACE_EVENT_PATH() macro, that allows the > > > developer to specify the path that the event will be seen in sysfs? > > > > Perhaps you could build that into the event class definition as well > > so each separate class in a subsystem can be placed in it's own > > sub-directory? > > > > That would make turning on and off specific classes trace points so > > much simpler than it now, espcially for XFS where we now have > 250 > > tracepoints that are mostly defined by event classes already... > > > I was working on creating a "TRACE_CATEGORY()" that allowed you to put > tracepoints into categories. Thus, these tracepoints will all still be > in the XFS system, but you can add hierarchical categories that let you > group and enable tracepoints in these groups. > > But I stopped this work since it was more ftrace specific than perf, and > I need to figure out how to continue my work on ftrace and at the same > time merge it towards perf. This has been taking much longer than I have > expected. Perhaps I should just finish that work, and then see how we > can make perf work with it too? That's nice. Does this "TRACE_CATEGORY()" can help to specify different event attribute value? /sys/devices/pci0000:00/0000:00:02.0/drm/card0/events |-- i915_gem_object_bind | |-- config | |-- type | |-- filter ==> filter for card0 /sys/devices/pci0000:00/0000:00:02.0/drm/card1/events |-- i915_gem_object_bind | |-- config | |-- type | |-- filter ==> filter for card1 In above example, the values of "config" and "type" are same. But the values of "filter" are different. Lin Ming > > -- Steve > > -- 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: Steven Rostedt on 23 Jul 2010 00:00 On Fri, 2010-07-23 at 10:45 +0800, Lin Ming wrote: > On Fri, 2010-07-23 at 10:14 +0800, Steven Rostedt wrote: > Does this "TRACE_CATEGORY()" can help to specify different event > attribute value? > > /sys/devices/pci0000:00/0000:00:02.0/drm/card0/events > |-- i915_gem_object_bind > | |-- config > | |-- type > | |-- filter ==> filter for card0 > > /sys/devices/pci0000:00/0000:00:02.0/drm/card1/events > |-- i915_gem_object_bind > | |-- config > | |-- type > | |-- filter ==> filter for card1 > > In above example, the values of "config" and "type" are same. > But the values of "filter" are different. No, it does not make a single event with different atts. It is just a way to group events. What you are showing is two events with the same name under two different groups. But there still only exists one event (the place that trace_i915_gem_object_bind() is located). -- Steve -- 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: Dave Chinner on 23 Jul 2010 00:30
On Thu, Jul 22, 2010 at 10:14:00PM -0400, Steven Rostedt wrote: > On Fri, 2010-07-23 at 11:37 +1000, Dave Chinner wrote: > > On Thu, Jul 22, 2010 at 09:54:04AM -0400, Steven Rostedt wrote: > > > On Thu, 2010-07-22 at 15:48 +0200, Ingo Molnar wrote: > > > > * Steven Rostedt <rostedt(a)goodmis.org> wrote: > > > > > > > Yeah - and the point of this submission is to allow the discussion of how to > > > > achieve these registrations. > > > > > > > > Driver authors will want to have some control - for example the place where > > > > the events directory shows up in sysfs within the driver's directory structure > > > > - etc. > > > > > > > > But we indeed want to automate it as much as possible. > > > > > > Perhaps we can create a TRACE_EVENT_PATH() macro, that allows the > > > developer to specify the path that the event will be seen in sysfs? > > > > Perhaps you could build that into the event class definition as well > > so each separate class in a subsystem can be placed in it's own > > sub-directory? > > > > That would make turning on and off specific classes trace points so > > much simpler than it now, espcially for XFS where we now have > 250 > > tracepoints that are mostly defined by event classes already... > > I was working on creating a "TRACE_CATEGORY()" that allowed you to put > tracepoints into categories. Thus, these tracepoints will all still be > in the XFS system, but you can add hierarchical categories that let you > group and enable tracepoints in these groups. Yes, that's pretty much what I was thinking of. > But I stopped this work since it was more ftrace specific than perf, and > I need to figure out how to continue my work on ftrace and at the same > time merge it towards perf. This has been taking much longer than I have > expected. Perhaps I should just finish that work, and then see how we > can make perf work with it too? I'm not fussed - it's more of a wishlist item right now. If it's in the pipeline, then I'm happy to wait until you've done all the hard work for me. ;) Cheers, Dave. -- Dave Chinner david(a)fromorbit.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/ |