pcp
[Top] [All Lists]

Re: systemtap/pcp integration

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: systemtap/pcp integration
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Mon, 21 Jul 2014 22:57:27 -0400
Cc: David Smith <dsmith@xxxxxxxxxx>, pcp@xxxxxxxxxxx, Systemtap List <systemtap@xxxxxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <861139755.14608867.1405992742567.JavaMail.zimbra@xxxxxxxxxx> (Nathan Scott's message of "Mon, 21 Jul 2014 21:32:22 -0400 (EDT)")
References: <53C83CB9.3020808@xxxxxxxxxx> <861139755.14608867.1405992742567.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
Hi, Nathan -

nathans wrote:

> [...]
> (OOC, what's {MODULE_NAME} in this context?)

It is usually a machine-generated unique identifier for the systemtap
script in question, such as "stap_deadbeefdeadbeefdeadbeef_2222".  It
is not generally predictable in advance.  (A user can override the
name, but that costs possible collisions.)


> [...] PMDA is written to be able to detect arrival/departure of new
> MMV files based on changes in a directory (and the location of that
> directory is parameterised via /etc/pcp.conf variables).  [...]

If we do end up sticking with this MMV approach, the PMDA would
probably need to use glob(3) or similar to search for
"/proc/systemtap/*/mmv" instead of "/proc/mmv/*".


> It also occurs to me that there's not really anything
> systemtap-specific about the kernel MMV instrumentation you've done,
> or is there?  [...]  It would be worth thinking about if the MMV
> bits in your script could become a more general kernel module for
> others to use too [...]

Yes, perhaps, though the path of code implementing a seemingly good
idea into the kernel is rarely smooth.  They generally dislike
infrastructure unless it's well-yearned-for.  So, if you wish to
pursue this goal, some serious selling on LKML will be needed.


- FChE

<Prev in Thread] Current Thread [Next in Thread>