From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6870 invoked by alias); 10 Jul 2008 02:30:44 -0000 Received: (qmail 6863 invoked by uid 22791); 10 Jul 2008 02:30:44 -0000 X-Spam-Status: No, hits=-2.5 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.31) with ESMTP; Thu, 10 Jul 2008 02:30:26 +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 m6A2UNS4021077; Wed, 9 Jul 2008 22:30:23 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6A2UNnQ014195; Wed, 9 Jul 2008 22:30:23 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.yyz.redhat.com [10.15.16.9]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6A2Toxd021705; Wed, 9 Jul 2008 22:30:23 -0400 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id CC22C8001FF; Wed, 9 Jul 2008 22:29:33 -0400 (EDT) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id m6A2THBA003976; Wed, 9 Jul 2008 22:29:17 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id m6A2TGc7003975; Wed, 9 Jul 2008 22:29:16 -0400 X-Authentication-Warning: ton.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: James Bottomley Cc: linux-kernel , systemtap@sourceware.org Subject: Re: [RFC] simple dprobe like markers for the kernel References: <1215638551.3444.39.camel__22002.9595810503$1215638656$gmane$org@localhost.localdomain> From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 10 Jul 2008 02:30:00 -0000 In-Reply-To: <1215638551.3444.39.camel__22002.9595810503$1215638656$gmane$org@localhost.localdomain> (James Bottomley's message of "Wed, 09 Jul 2008 16:22:31 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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/msg00118.txt.bz2 James Bottomley writes: > I've been looking at using the existing in kernel markers for dtrace > named probing in systemtap. What I find is that they're a bit > heavyweight when compared to what dtrace does (because of the way > they drop stubbable calling points). > This patch adds incredibly simple markers which are designed to be used > via kprobes [+ dwarf]. [...] > [...] The disadvantage is that it's really unusable for rolling > your own marker probes because it relies on the dwarf2 information > to locate the probe point for kprobes and unravel the local > variables of interest, so you need an external tool like systemtap > to help you. [...] Another disadvantage is one that came up earlier when markers were initially thought up: that something so invisible to the compiler (no code being generated in the instruction stream, after optimization, may be impossible to locate: not just the statement but also the putative parameters. Long ago, someone proposed inserting an asm("nop") mini-markers into the instruction stream, which could then be used as an anchor to tie a kprobe to, so that would solve the statement-location problem. But it doesn't help assure that the parameters will be available in dwarf, so someone else proposed adding another asm that just asks the parameters to be evaluated and placed *somewhere*. Each asm input constraint was to be the loosest possible, so as to not force the compiler to put the values into registers (and evict their normal tracing-ignorant tenants). I believe this combination was never actually built/tested, partly because people realized that then the compiler would always have to evaluate parameters unconditionally, whether or not a kprobe is present. (To do it otherwise would IIRC require the asm code to include control-flow-modification instructions, which would surprise gcc.) So that's roughly how we arrived at recent markers. They expose to the compiler the parameters, but arrange not to evaluate them unless necessary. The most recent markers code patches nops over most or all the hot path instructions, so there is no tangible performance impact. - FChE