Re: Questions regarding systemtap syntax for profiling...

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


On Thu, Jun 09, 2005 at 01:17:21AM -0700, Spirakis, Charles wrote:

> > Not quite - in the "stopwatch" case, we=20
> > don't respond to changes in the time
> > fluent, but rather to the changes in PC.
> 
> I'm not sure I understand. What do you mean by "respond to changes in
> the time fluent"?

The stopwatch case took snapshots of "time" as measured by performance
monitoring counters, at events defined by the program tripping across
(kprobes) breakpoints.  OTOH the profiling case took snapshots of
PC/registers, at events defined by tripping across timer counts.  They
are duals of one another.


> Regarding the various syntax examples, it is common to want ratios of
> event counts which means getting multiple counts at the same time
> (limited by the pmu hardware) For example, in stopwatch mode, one may
> want instructions retired, clockticks and cache misses. Can you string
> together the pmc_startwatch() syntax?  [...]

I did not mean to give the impression that there is already a finished
scheme for all this.  If anything, it's the opposite.  

I am hoping that a domain expert such as yourself performs the
necessary analysis to enumerate the range of requirements for probe
point specificiation variants, data values, compositions, usage
scenarios, etc.  The expert would ideally complete a copy of that
"tapset description template" document and put it into the source tree
along the others.  Then this document would later be used as a basis
for *implementing* the interface.

As a part of developing this, I would be happy to help guide what sort
of existing (or if necessary, extended) syntax patterns may be useful
to represent the required capabilities.


> [...]
> 1) have the systemtap transilator do the translation directly
> 2) have the systemtap transilator call another library (pass in the
> string, get back a list of register/value pairs that need to be
> touched).

If the operating model remains a batch user-land translation process,
then this library would be linked into the translator executable and
would function as the normal process as much as the first case.


> [...]
> As for virtualization. Are we willing to consider the use of the
> perfmon2 infrastructure?
> 
> Homepage http://www.hpl.hp.com/research/linux/perfmon
> api spec http://www.hpl.hp.com/techreports/2004/HPL-2004-200R1.html
> [...]

Certainly.


- FChE