Re: systemtap/pcp integration

[David Smith <dsmith at redhat dot com>]

On 07/18/2014 10:49 AM, Frank Ch. Eigler wrote:
> 
> Hi, David -
> 
>> Here's a small update on the prototype systemtap/pcp integration work
>> I'm doing. 
> 
> Thanks, what a great start.
> 
>> I've create a systemtap branch, called 'dsmith/mmv' that contains
>> all my work. Basically this work allows systemtap to create 'mmv'
>> memory mapped files.
> 
> (That's git://sourceware.org/git/systemtap.git branch dsmith/mmv.)
>
>> [...] The code works for the attached script, but I'm sure it is
>> quite fragile. Things like locking, error checking, documentation,
>> etc. need to be done. [...]
> 
> Overall, are you happy with the general approach of reusing the exact
> MMV format (and thus the PMDA)?

That's a good question. I certainly started with reusing the exact MMV
format because that's a working format with an existing data consumer on
the pcp side of things.

Note that the current systemtap implementation is actually a subset of
the full pcp MMV format - currently it only supports 64-bit integers
(with string values to come).

However, as I've worked with the MMV format I've come to realize its
limitations. As Nathan has pointed out in another email, the MMV format
is designed to only support exporting values, and isn't suited for more
event-like tracing. As far as the more technical side of things goes,
some of the internal offset logic might be done better/differently.

> At one point I suggested reworking the earlier prototype so that the
> bulk of the MMV format's emulation would be based on tapset script
> code (and possibly more declarative / dynamic / safe) rather than C.
> Have you come to any conclusions about the propriety of that?

I've been focused on other things, like reworking the allocation logic.
As you describe it above, I'm not sure I see where you are headed.
Certainly when I add systemtap's dyninst support into the picture, I was
planning on sharing that code between systemtap's linux and dyninst
runtimes.

> How much post-initialization change can the MMV format tolerate, as
> regarding indom contents or metric availability?  I assume such
> metadata changes are synchronized with the PMDA via the generation
> numbers.  Moving around contents of the mmap region as in
> __stp_mmv_alloc_data_item sounds like it leaves the data inconsistent
> during the process; does it need similar protection?

The MMV format doesn't support any post-initialization changes - once
you call "start" the file format can't change without removing and
recreating the file. (The reader knows "start" has been called based on
when the generation numbers match.)

As far as systemtap is concerned, all the memory moving that
__stp_mmv_alloc_data_item() does is done before calling "start", so the
data being inconsistent as far as the reader is concerned doesn't
matter. For the linux runtime side of things, we could not allow reads
of the memory-mapped data until "start" has been called (and the data is
consistent).

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)