From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3756 invoked by alias); 3 Mar 2006 21:16:41 -0000 Received: (qmail 3747 invoked by uid 22791); 3 Mar 2006 21:16:40 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Mar 2006 21:16:39 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k23LGbwm000687 for ; Fri, 3 Mar 2006 16:16:37 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k23LGb106934; Fri, 3 Mar 2006 16:16:37 -0500 Received: from vpn83-186.boston.redhat.com (vpn83-186.boston.redhat.com [172.16.83.186]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k23LGZNG017544; Fri, 3 Mar 2006 16:16:36 -0500 Subject: Re: tutorial draft checked in From: Martin Hunt To: "Frank Ch. Eigler" Cc: systemtap@sources.redhat.com In-Reply-To: <20060303175653.GE6873@redhat.com> References: <20060303175653.GE6873@redhat.com> Content-Type: text/plain Organization: Red Hat Inc. Date: Fri, 03 Mar 2006 21:16:00 -0000 Message-Id: <1141420594.3595.46.camel@dragon> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-3.fc4) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00696.txt.bz2 On Fri, 2006-03-03 at 12:56 -0500, Frank Ch. Eigler wrote: > I checked in a draft of the systemtap tutorial (/doc/tutorial). Very Nice! On first reading, I have only a few minor comments. Section 3.5 >This operation is efficient (taking a shared lock) because the >aggregate values are kept separately on each processor, and are only >aggregated across processors on request. Surprised me. I checked and this accurately described the current implementation, but the shared lock is unnecessary and should probably not be mentioned. >b[cpu(),execname()] <<< 1 # better than ++ [...] >print(@hist_log(b[0,"zsh"])) print an "ascii art" >logarithmic histogram of the same data stream Indexing by cpu() here complicates the example, especially after discussing how aggregates store information per-cpu. And the histogram example won't print anything like a histogram because the values are all 1. I suggest you change these to something clearer. writes[execname()] <<< count print(@hist_log(writes["zsh"])) print an "ascii art" logarithmic histogram of the same data stream Section 3.6 What about running out of memory? Need to mention that arrays are preallocated, fixed in size, can overflow, and what happens when they do. That may change in the future. Section 4.3 >Since systemtap cannot examine the C code to infer these >types, an optional type annotation syntax is available >for explicitly declaring them. If it is optional, what happens if the types are not declared? Is there a default? 4.4 The ideas here are fine. Maybe it needs to be clearer that people shouldn't prefix their tapset functions with "TAPSET_" but with the unique tapset name followed by underscore. Martin