From: David Smith <dsmith@redhat.com>
To: Nathan Scott <nathans@redhat.com>
Cc: Systemtap List <systemtap@sourceware.org>, pcp <pcp@oss.sgi.com>
Subject: Re: [pcp] systemtap/pcp integration
Date: Tue, 22 Jul 2014 14:50:00 -0000 [thread overview]
Message-ID: <53CE7A2E.6010306@redhat.com> (raw)
In-Reply-To: <861139755.14608867.1405992742567.JavaMail.zimbra@redhat.com>
On 07/21/2014 08:32 PM, Nathan Scott wrote:
> Hi David,
>
> ----- Original Message -----
>> [...]
>> Note that systemtap will create a file called 'mmv' in
>> /proc/systemtap/{MODULE_NAME}. I've just been using pcp's 'mmvdump'
>> utility to dump the contents of the /proc/systemtap/{MODULE_NAME}/mmv
>> file. Currently the pcp mmv pmda only looks in one place for mmv files,
>> but it might be possible to create a symbolic link to systemtap's mmv
>> file to make it happy.
>
> (OOC, what's {MODULE_NAME} in this context?)
As Frank mentioned, {MODULE_NAME} is the name of the module, usually
autogenerated.
> A symlink would sorta work but it feels like a bit of a workaround - the
> 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). I'd not recommend trying to
> find it within a stap script ... I imagine it will be cleaner if we go
> for separate user/kernel locations for MMV files.
The symlink feels like a bit of a workaround, because it *is* one. Long
term we certainly want a better way to find the systemtap MMV files.
> Attached patch (lightly tested) implements the PCP side of things with
> that in mind - with this patch (and making the kernel code manage the
> lifecycle of separate /proc/mmv/* entries), things should begin to work
> out-of-the-box (the MMV PMDA is already default-enabled in the default
> pmcd config file, so everything else is in place for you).
This code sounds like a step in the right direction.
Thanks.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
next prev parent reply other threads:[~2014-07-22 14:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 21:14 David Smith
2014-07-18 15:49 ` Frank Ch. Eigler
2014-07-18 17:02 ` David Smith
2014-07-18 18:27 ` Frank Ch. Eigler
2014-07-22 14:25 ` David Smith
2014-07-22 15:21 ` Frank Ch. Eigler
2014-07-22 21:02 ` David Smith
2014-07-18 21:10 ` [pcp] " William Cohen
2014-07-21 15:43 ` David Smith
2014-07-21 15:54 ` William Cohen
2014-07-22 1:32 ` Nathan Scott
2014-07-22 2:57 ` Frank Ch. Eigler
2014-07-22 14:50 ` David Smith [this message]
2014-07-23 10:29 ` [pcp] " Nathan Scott
2014-07-23 14:42 ` Frank Ch. Eigler
2014-07-24 7:40 ` Nathan Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53CE7A2E.6010306@redhat.com \
--to=dsmith@redhat.com \
--cc=nathans@redhat.com \
--cc=pcp@oss.sgi.com \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).