This is the mail archive of the systemtap@sources.redhat.com 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: comments from prospective VM tapset author


jkenisto wrote:

> Here are notes from conversations with Darren Hart, who is working
> on VM instrumentation that we hope will lead to a tapset.  [...]

Thank you.  Such information is valuable.

> [...]  Darren has been using kprobes and jprobes [...]  [...]  -
> Instrumentation is a library of functions [collecting] an advertised
> set of values [...]  A SystemTap-generated handler would call such a
> function to obtain the advertised values.

There is mixing of active (probing, servicing callbacks from kprobes)
and passive (value gathering, servicing calls from systemtap/runtime)
elements here.  There is likewise a mixing of the concept of
"instrumentation", both as self-contained end-user program versus as a
tapset/extension for use by a higher level script.

It would be good to break apart these aspects somehow, so that one can
contemplate implementation options separately.  For example, when
Darren wants "how many pages requested / freed to get them", does he
mean that these numbers are available in the kernel, just need
exposure to a user-level script for printing?  OK, then where exactly
can those numbers be found today?  Or do the numbers have to be
computed indirectly, perhaps via some active probes?  How?


> [...][Re. the tapset template]
> - "Seems like a lot.  Who fills it out?  Who reads it?"

The idea is for domain experts or friends to record the information.
For example, it is a place to put pseudocode that gathers information
from low-level data structures, for data which could ultimately end up
as systemtap variables.  It is read by people who want to write
tapsets to implement the extensions, or the end-user scripts to call
them.

In some cases, an end-user may only know that some kinds of
information is required, but not know how to find that within the
kernel.  Thus only the "end-user" portions of the template might be
filled in, awaiting for someone to figure out how to provide that
information within a tapset.


> - Background should be combined with Motivation.
> - Target software should be obvious from Motivation/Background.
> - Interesting values, Data collection, and Data presentation should be
> combined.

I'm sure the template will evolve as more examples come about.
I'll assemble one or two based upon Darren's text.


- FChE


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