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


wcohen wrote:

> [...]  I have written up material describing how I would think that
> systemtap could use the performance monitoring hardware. [...]

It would be helpful to see a hypothetical script that would use the
proposed API.

Anyway, beyond such script language design issues, the hard part has
been the provision of *some* kernel-side API in terms of which this
stuff can be implemented.  How is that going?


> [...]
> perfmon_allocate_counter:long (event_spec:string)
> perfmon_free_counter:long (event_handle:long)
> perfmon_create_context:long ()
> probe kernel.perfmon.sample(event_handle:long) {/*body*/}

These sound rather like suitable lower level functions that the
translator could use under the covers, and not functions that are
wisely exposed at the script level.

Specifically, I would rather expose each particular event_spec source
as a first-class probe point construct:

# probe perfmon.sample("event_spec") { /* body */ }

This would entail calls to such alloc/free/create functions being
emitted in the probe (un)registration boilerplate.  "event_spec"
could perhaps be expanded into several probe point components, and
result in a periodic run of the handler much like timer.ms(N):

# probe perfmon.counter("tlbmiss").cpu(0).sample(1000) { /* ... */ }


That seems to leave just free-running counter operations:

> perfmon_get_counter:long (event_handle:long)
> perfmon_start_counter:long (event_handle:long)
> perfmon_stop_counter:long (event_handle:long)

One possible way to cast these into the language, and yet retain
automatic initialization/cleanup, might be this:

# probe perfmon.counter("tlbmiss").cpu(0).run { h = $handle }
# probe ANY { perfmon_{get,start,stop}_counter (h) }
# global h

What this would do is to have that perfmon.* probe handler run just
once (during initialization), supplying the script with the
system-assigned handle for this counter.  Then another probe (though
probably not a "begin" one) can use that handle value to manipulate
the counter.


- FChE


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