From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29496 invoked by alias); 22 Jul 2014 14:25:16 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 29487 invoked by uid 89); 22 Jul 2014 14:25:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 22 Jul 2014 14:25:13 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6MEP6BO022095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Jul 2014 10:25:07 -0400 Received: from t540p.usersys.redhat.com (vpn-54-16.rdu2.redhat.com [10.10.54.16]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6MEP2kI013213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Jul 2014 10:25:05 -0400 Message-ID: <53CE743E.9030807@redhat.com> Date: Tue, 22 Jul 2014 14:25:00 -0000 From: David Smith User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: Systemtap List , pcp Subject: Re: systemtap/pcp integration References: <53C83CB9.3020808@redhat.com> <53C94A6F.4080808@redhat.com> <20140718182751.GE20905@redhat.com> In-Reply-To: <20140718182751.GE20905@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q3/txt/msg00070.txt.bz2 On 07/18/2014 01:27 PM, Frank Ch. Eigler wrote: > Hi - > > dsmith wrote: > >> [...] >>> Overall, are you happy with the general approach of reusing the exact >>> MMV format (and thus the PMDA)? >> >> [...] >> 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. > > An application of pmda/mmv & pmda/logger to the same stap module could > perhaps accomplish both goals (assuming we consider the pcp events > overengineered to the extent that supplying timestamped strings is > sufficient). Have you considered an alternative unified design? > > This reminds me of another PCP PMDA we've mentioned in the past: a > JSON fetcher/parser. We'll need something like this for a variety of > non-systemtap purposes too (interop with JSON-producing tools). What > if stap were to produce pcp metrics in the form of /proc/systemtap/* > JSON files that the PMDA would read on demand? (The cost of the > parsing overhead may be low enough not to worry about it.) A separate > generated JSON file could provide metadata. That format could be rich > enough to contain events too (mapped from arrays of string). I think a JSON fetcher/parser is a good idea. >>> 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. > > To spell it out, the idea was to encode the mmv format logic > (including metadata management) within a stap tapset script instead of > as C in the runtime. Then the C runtime would need to do nothing but > provide a memory-mapped-byte-array kind of abstraction, and a way for > the script code to read/write it (maybe a variant of > sprintf("%b...")?). Hmm. I think I see where you are going with this, but I don't know if it will work well for a couple of reasons. One is that you don't just write to this array, you have to be able to read it back (in order to shuffle things around, hook up instances to indoms, etc.). In addition, the best way to ensure that a client can read the data produced by the mmv stuff is to use the same header file so we know the data is laid out the same way. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)