From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4384 invoked by alias); 5 Apr 2006 16:06:52 -0000 Received: (qmail 4376 invoked by uid 22791); 5 Apr 2006 16:06:52 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ausmtp04.au.ibm.com (HELO ausmtp04.au.ibm.com) (202.81.18.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Apr 2006 16:06:49 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp04.au.ibm.com (8.13.6/8.13.5) with ESMTP id k35GFicF161572 for ; Thu, 6 Apr 2006 02:15:45 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k35G9xB0214008 for ; Thu, 6 Apr 2006 02:10:04 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11/8.13.3) with ESMTP id k35G6ThK029253 for ; Thu, 6 Apr 2006 02:06:29 +1000 Received: from d23m0017.cn.ibm.com (cnnco04.cn.ibm.com [9.181.122.142]) by d23av03.au.ibm.com (8.12.11/8.12.11) with ESMTP id k35G6TnG029197; Thu, 6 Apr 2006 02:06:29 +1000 In-Reply-To: To: fche@redhat.com (Frank Ch. Eigler) Cc: systemtap@sources.redhat.com Subject: Re: adding statements in alias definition as epilogue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Guang Lei Li Date: Wed, 05 Apr 2006 16:06:00 -0000 X-MIMETrack: Serialize by Router on d23m0017/23/M/IBM(Release 6.53HF654 | July 22, 2005) at 04/06/2006 00:07:43, Serialize complete at 04/06/2006 00:07:43 Content-Type: text/plain; charset="US-ASCII" 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-q2/txt/msg00043.txt.bz2 systemtap-owner@sourceware.org wrote on 2006-04-05 20:03:23: > Guang Lei Li writes: > > > [...] > > probe addevent.tskdispatching.* {} > > > > will cause both addevent.tskdispatch.cpuidle.backtrace & > > addevent.tskdispatch.cpuidle to be triggered. > > Actually, it doesn't: the wildcard only consumes one component of the > probe point name. I tried, and found: probe addevent.tskdispatching.* = probe addevent.tskdispatching.cpuidle but addevent.tskdispatching.cpuidle.backtrace is removed away from the generated probes. > > > And it also enables to turn on/off backtrace for each event > > separately instead of turn on/off all backtraces as a whole. > > I see that, but is this capability important & useful? Plus, apropos > an earlier message, how does the concept of high-performance binary > tracing mesh at all with slow and bulky backtrace generation? > Because current backtrace printing is costly, so I want to let the user to only turn on backtrace for those events necessary. But you are right, backtrace printing is too slow, we need a faster way of getting the backtrace > > > [...] Besides my specific need of alias definition as epilogue, I > > think it is also useful if you want a filter: [...] > > > > probe derived_probe := alias_with_filter_codes { > > filter_on = 1 > > scsi_lun = 2 > > scsi_dev_major = 3 > > } > > This style of usage could be accommodated with explicit code > (analogous to "if (target() != pid()) next") instead of alias epilogues. It is only suitable for filtering by pid, which provides a way of passing in the target pid by "stap -c cmd" or "stap -x targetid". But how can you pass in filter_on, scsi_lun & scsi_dev_major? The newly arguments support in stap could make it, but it seems not a good solution in this example. > > > - FChE