From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24295 invoked by alias); 18 Jul 2014 17:02:55 -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 24286 invoked by uid 89); 18 Jul 2014 17:02:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=unavailable 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; Fri, 18 Jul 2014 17:02:53 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6IGPLPH021755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Jul 2014 12:25:21 -0400 Received: from t540p.usersys.redhat.com (vpn-51-23.rdu2.redhat.com [10.10.51.23]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6IGPJL1022385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Jul 2014 12:25:20 -0400 Message-ID: <53C94A6F.4080808@redhat.com> Date: Fri, 18 Jul 2014 17:02: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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q3/txt/msg00039.txt.bz2 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)