From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28262 invoked by alias); 2 Jul 2008 22:38:50 -0000 Received: (qmail 28241 invoked by uid 22791); 2 Jul 2008 22:38:49 -0000 X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_34,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; Wed, 02 Jul 2008 22:38:13 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m62McBZc014559 for ; Wed, 2 Jul 2008 18:38:11 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [10.16.255.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m62McAGQ019023; Wed, 2 Jul 2008 18:38:10 -0400 Received: from [10.16.3.219] (dhcp-100-3-219.bos.redhat.com [10.16.3.219]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m62Mc9ol011838; Wed, 2 Jul 2008 18:38:10 -0400 Message-ID: <486C0303.2030404@redhat.com> Date: Wed, 02 Jul 2008 22:38:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Theodore Tso CC: "Frank Ch. Eigler" , Roland McGrath , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Subject: Re: Potential Systemtap topics for the Kernel Summit References: <20080630181959.GA7988@mit.edu> <20080630192533.GE21660@redhat.com> <20080630201031.GF7988@mit.edu> <20080630204219.GA6631@redhat.com> <20080701024140.GB28143@mit.edu> <20080701070746.C6DAD15420E@magilla.localdomain> <20080701101507.GB22717@mit.edu> <20080701200632.6790A1541F5@magilla.localdomain> <20080701231327.GA5829@mit.edu> <20080702192519.GA31206@redhat.com> <20080702213938.GA23574@mit.edu> In-Reply-To: <20080702213938.GA23574@mit.edu> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes 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 X-SW-Source: 2008-q3/txt/msg00025.txt.bz2 Theodore Tso wrote: > On Wed, Jul 02, 2008 at 03:25:19PM -0400, Frank Ch. Eigler wrote: >> So, one way a kernel developer could help write a tapset piece for us >> is to encapsulate this into a tapset script fragment: >> >> probe vfs.read = kernel.function ("vfs_read") >> { >> dev_nr = $...expression >> inode_nr = $...expression >> } >> >> **** or **** >> >> Kernel maintainers could add a marker or two right into their C code: >> >> { >> /* ... */ >> trace_mark (vfs_read, "dev %u inode %u whatever %s", >> expression1, expression2, whatever); >> /* ... */ >> } > > So it sounds like potential Systemtap topics for the kernel summit > might include: > > A) Enhancements to kbuild to better support kernel developers who want > to use systemtap. > > B) Discussion of list of tapsets and markers that would be useful for > System administrators wanting to use systemtap. This is one place > where if someone could volunteer to examine some of the Dtrace > examples and blog entries where Dtrace users have raved about how > Dtrace saved their bacon by instantly identifying some performance > problem, and then assemble a "tapset or marker WANTED" bounty list, > that would be very useful. One potential problem is that I suspect > kernel developers may not know or have the intuition of what sort of > markers or tapsets would be most useful. Having a targetted wish list > would be very useful. (We might then have some discussions about > whether a particular tapset or marker is too hard to maintain, or > represents too much of a performance hit, but at least would be > dealing with concrete requests.) I think, not only tapset, but also (a part of) runtime and building script should be merged into kernel tree. Some of them depends on kernel features and currently we uses autoconf-like method for checking whether we can use those features. Obviously, this method has a limitation. :-( > C) Whether tapsets/markers should be maintained inside the kernel, and > if so, how. We have been discussing how we can push markers into upstream on LKML. http://lkml.org/lkml/2008/6/2/463 http://lkml.org/lkml/2008/6/20/250 as far as I know, current discussion point of markers are; - Interface Ugliness Markers needs printf-style format string, and some people complains that is ugly. - KABI exposure some Markers expose internal kernel structures to user space, it is not useful because those internal structures rapidly change. And also, might we treat it as stable ABIs? - Maintenance issue We might have to consider maintenance cost of markers which are scattered throughout the kernel. If those markers perpetuate the logic and code, it can prevent linux's evolution. And subsystem maintainers might want not to get involved in maintenance of markers embedded in their code. For resolving first and second issues technically, Mathieu proposed tracepoint layer. http://lkml.org/lkml/2008/6/25/426 I think we still have maintenance issue. So we need to discuss clear policies for marker maintenance which don't prevent linux evolution. For example, - Subsystem maintainers or developers can freely modify or remove trace points by their patch, if needed. - Marker/Tracepoint maintainers should follow upstream changes. - No one can NAK a patch from the reason that it modifies or removes trace points. etc. > > D) What is the right way to do user probes. > > Of course, if some of these topics are handled via e-mail before the > kernel summit, even better. But somehow, I'm guessing there will > still be more to talk about. :-) > > The bottom line is more communication between the kernel and systemtap > developers is a good thing (and getting more kernel developers to use > systemtap would be a good start). Yeah, we need to have a party to talk each other. :-P Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com