This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposed systemtap access to perfmon hardware


William Cohen wrote:

[snip]

perfmon_create_context:long ()

The perfmon_create_context command sets up the performance monitoring
hardware for the allocated contexts and starts the counters running.
If successful, the function will return zero. If the operation is
unsuccessful because an error code will be returned. This function
should only be used in probe begin. (FIXME list error code returned.)


I'm confused about the relationship between this function and perfmon_start_counter, since starting the counters is mentioned in both. Could you explain at what point this function is invoked and what the purpose of the context is? I'm not real familiar with the perfmon2 interface, but just on the face of it, your context doesn't seem like a one-to-one fit with the way contexts are used in perfmon2. In perfmon2, a context is created first, which is then passed in to the calls for setting up events, thereby associating those events with the context. Then 'start' uses the context to set up the PMU for all requested events and begin the counting.


[snip]


perfmon_start_counter:long (event_handle:long)

The event_handle passed in indicates which counter to start. The value
is returned as a 64-bit long of the current counter value. The return
value is undefined for an invalid event_handle.


I think individually starting counters is problematic at a couple different levels. On some architectures (like PowerPC64), you don't have fine-grained control over each counter. Also, one usually wants all counters to begin counting at the same time. Maybe I'm misinterpreting what the intention of this function is.

[snip]


EVENT SPECIFICATION

The performance monitoring events are specified in strings. The
information at the very least include the event name being monitored


Will, you allude to this in a later posting, but I'll reiterate here. Should the event name be the native event name for the arch? Or some generic name that is mapped to a native name by some mechanism? Or either (as in PAPI)?

by the counter.  Additional information would include a event mask to
specify subevents, whether to count in kernel or user space, whether
to keep track of counts on a per thread or per CPU basis, and the
interval for the sampling.

(FIXME more detail on the string compositions)


SYSTEMTAP PERFORMANCE HARDWARE ACCESS IMPLEMENTATION


The SystemTap access performance monitoring hardware is planned to be
built on the perfmon2 kernel support. The perfom2 provides reservation
and access to the performance monitoring hardware on ia64, i386, and
PowerPC processors. The perfmon2 support is not yet in the upstream
kernels, but patches are available.


As a proof of concept, I agree that this is the best route. Reinventing the wheel would be useless. Maybe building this prototype might help with refining the perfmon2 interface.



Regards,
-Maynard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]