From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31566 invoked by alias); 20 Nov 2009 22:47:52 -0000 Received: (qmail 31559 invoked by uid 22791); 20 Nov 2009 22:47:51 -0000 X-SWARE-Spam-Status: No, hits=-2.4 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) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Nov 2009 22:46:48 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAKMkd3Z026606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Nov 2009 17:46:39 -0500 Received: from fche.csb (vpn-243-193.phx2.redhat.com [10.3.243.193]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAKMkcnH007834; Fri, 20 Nov 2009 17:46:39 -0500 Received: by fche.csb (Postfix, from userid 2569) id 828D4580D8; Fri, 20 Nov 2009 17:46:38 -0500 (EST) To: James Y Knight Cc: systemtap@sourceware.org Subject: Re: Dynamically enabling/disabling probe points from within stap script References: <99F43110-6332-47AB-A399-21BCCFA48664@fuhm.net> From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 20 Nov 2009 22:47:00 -0000 In-Reply-To: <99F43110-6332-47AB-A399-21BCCFA48664@fuhm.net> (James Y. Knight's message of "Fri, 20 Nov 2009 16:52:02 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-q4/txt/msg00627.txt.bz2 James Y Knight writes: > Is there any plan to allow the ability to dynamically and > efficiently enable and disable probes from within the systemtap > script? Yup. > I know you can do: > probe process(...).mark("foo") if (whatever) {} > but that isn't efficient [...] That's right. We have had a rough design for this, but kind of forgot to finish the job. Your note and PR10995 should bring attention back to the problem. (One drawback of actually disarming/rearming probes is that because of the unavoidable latency between intended rearming and actual rearming, the script may experience unknown missed probes.) > Also nice would be a way to (efficiently!) say "run this probe every > N times the location is hit". Since this would require counting each location hit, and thus the activation of the corresponding low-level probe, this would be equivalent to adding something like this into the probe handler if (count++ % 100) next; - FChE