From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31109 invoked by alias); 22 Jul 2009 14:39:30 -0000 Received: (qmail 31096 invoked by uid 22791); 22 Jul 2009 14:39:27 -0000 X-SWARE-Spam-Status: No, hits=-2.3 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.43rc1) with ESMTP; Wed, 22 Jul 2009 14:39:14 +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 n6MEdC3W026361 for ; Wed, 22 Jul 2009 10:39:12 -0400 Received: from fche.csb (vpn-225-153.phx2.redhat.com [10.3.225.153]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n6MEd9UX032762; Wed, 22 Jul 2009 10:39:10 -0400 Received: by fche.csb (Postfix, from userid 2569) id 5C9AB58481; Wed, 22 Jul 2009 10:39:04 -0400 (EDT) To: Mark Wielaard Cc: Stan Cox , systemtap@sourceware.org Subject: Re: new static user probe types References: <4A453D09.60600@redhat.com> <4A5E0195.5080803@redhat.com> <4A64B8AF.6030304@redhat.com> <1248259327.7890.29.camel@springer.wildebeest.org> From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 22 Jul 2009 14:39:00 -0000 In-Reply-To: <1248259327.7890.29.camel@springer.wildebeest.org> (Mark Wielaard's message of "Wed, 22 Jul 2009 12:42:07 +0200") 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-q3/txt/msg00181.txt.bz2 Mark Wielaard writes: > So uprobes is the clear winner for almost zero-overhead when > disabled. [...] But it has the largest overhead when > enabled. Clearly we want the uprobe mechanism when probes are > disabled, but the utrace mechanism when probes are enabled! [...] Yup. > [...] It would also help with implementing the idea for the ENABLED > mechanism idea suggested in [PR10013]. Or how about this. We could expand STAP_PROBE(...) to { extern char stap_probe_NNNN_enabled_p; if (unlikely(stap_probe_NNN_enabled_p)) { /* current inline-asm stuff, but adding &enabled_p to the descriptor struct. */ } } Since this FOO_enabled_p variable would be initialized to 0, this would allow bypass of all the instrumentation inline-asm in the instrumentation-off case. To turn on the instrumentation, the systemtap runtime would poke at the target process's memory to (atomically) increment that flag byte, and vice versa. (Increment instead of set, in case multiple systemtap sessions are targeting the same process.) The inline-asm inside could be the fastest enabled variant, probably the kprobe-based one. (This would make user-space sdt.h usable without utrace & uprobes.) The explicit ENABLED() test from PR10013 could use the same flag variable, and thus piggyback on the same run-time mechanism. (Its declaration would have to be put into some dtrace-script-generated header file, I guess.) - FChE