From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19136 invoked by alias); 7 Jul 2008 11:19:18 -0000 Received: (qmail 19127 invoked by uid 22791); 7 Jul 2008 11:19:17 -0000 X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Jul 2008 11:18:57 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KFok8-0003VT-Ba for systemtap@sources.redhat.com; Mon, 07 Jul 2008 11:18:52 +0000 Received: from 209.167.232.100 ([209.167.232.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jul 2008 11:18:52 +0000 Received: from fche by 209.167.232.100 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Jul 2008 11:18:52 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: systemtap@sources.redhat.com From: fche@redhat.com (Frank Ch. Eigler) Subject: Re: [Ksummit-2008-discuss] DTrace Date: Mon, 07 Jul 2008 11:19:00 -0000 Organization: Red Hat (Brantford, Ontario, Canada) Message-ID: References: <20080629084002.GA24131@lst.de> <20080630051034.GA4970@in.ibm.com> <20080630112913.GA18817@lst.de> <20080630171246.GB21660@redhat.com> <20080706123414.GA9265@lst.de> <20080706154612.GL2881@redhat.com> <20080706163533.GA16721@2ka.mipt.ru> <20080706182307.GA29895@2ka.mipt.ru> <20080706213920.GA1936@redhat.com> <20080707055753.GB26263@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 209.167.232.100 User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:03TRkX74g/XZ0PtsrTz8VitBTzE= X-NNTP-Posting-Host: ton.yyz.redhat.com 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/msg00064.txt.bz2 Evgeniy Polyakov writes: >> OK, so you think systemtap should go into the kernel ... > > Getting history of systemtap, I'm not sure it will be easily possible :) > But it is good project for overall Linux advertisement. > Personally I will not use it, since it is simpler (and very likely > has smaller performance overhead) to put various kinds of counters > all over needed places to get required statistics for hot pathes > like VM and put debug prints in the slow parts. You may be right for your specific use scenario, or you may be mistaken. That is a separate matter from systemtap implementation. >> [...] >> ... but now systemtap stay out to userspace? I don't understand. > > You asked how to get needed information. It can be accessed via ptrace, > so there is no need to have additional kernel module to get it. You would need to delve deeper into the problem domain then to understand why dynamic probing is useful to people, and why nonintrustive user-space probing is useful to people. Opinions about "how" to implement something less are not that useful if one didn't understand/agree-with the "why" (requirements) and "what" (design) in the first place. >> > (btw, does systemtap has the same complexity of script writing? >> >> If you point out an example of what you consider a complex dtrace >> script, I can try to answer that. > > Things like syscall::*read:entry, syscall::*write:entry > this->vnodep = this->filep != 0 ? this->filep->f_vnode : 0; > I.e. 'this' and 'self' pointer "this" in dtrace is shorthand for a thread-specific named data field. In systemtap, one might use an explicit associative-array expression "filep[tid()]" to save such values between probes. FWIW, this script does not strike me as that complex - I've seen much "worse", both there and in systemtap. Nor does it strike me as unnecessarily complex, considering how you'd have to do the same thing in C code or kprobes or user-space audit or whatever. YMMV. - FChE