From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25755 invoked by alias); 10 Jul 2008 14:23:52 -0000 Received: (qmail 25717 invoked by uid 22791); 10 Jul 2008 14:23:49 -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 14:23:18 +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 m6AENF8p006407; Thu, 10 Jul 2008 10:23:15 -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 m6AENFZj004873; Thu, 10 Jul 2008 10:23:15 -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 m6AEMgHX008262; Thu, 10 Jul 2008 10:23:14 -0400 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 7A3B18001FF; Thu, 10 Jul 2008 10:22:25 -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 m6AEM94o011185; Thu, 10 Jul 2008 10:22:09 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id m6AEM8E9011184; Thu, 10 Jul 2008 10:22:08 -0400 Date: Thu, 10 Jul 2008 14:23:00 -0000 From: "Frank Ch. Eigler" To: James Bottomley Cc: linux-kernel , systemtap@sourceware.org Subject: Re: [RFC] simple dprobe like markers for the kernel Message-ID: <20080710142208.GC1213@redhat.com> References: <1215638551.3444.39.camel__22002.9595810503$1215638656$gmane$org@localhost.localdomain> <1215697794.3353.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1215697794.3353.5.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i 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/msg00122.txt.bz2 Hi - On Thu, Jul 10, 2008 at 08:49:54AM -0500, James Bottomley wrote: > [...] > > 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. > > Actually, I listed that one as an advantage. But, in order to be > completely zero impact, the probe cannot interfere with optimisation, > and so you run the risk of having the probe point do strange things > (like it's in the middle of a loop that gets unrolled) or that the > variables you want to advertise get optimised away. > > All of this is mitigated by correct selection of the probe points and > the variables. Well, you can test your theory: replace some "tracepoints" or markers or printk's with this, and see if systemtap (or gdb) can get at the same data. When "correct selection" is a function of any particular compiler's optimization algorithms, it will be difficult for a human programmer to get it right. > > 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 you don't need a nop ... you just need a line number. That's *if* the line number ends up being resolvable back to a PC. In fact, since there is no code emitted for it, that particular line number will not actually appear in DWARF line records. > > 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). > > Actually, it does. Assuming the probe is placed in the code by someone > who knows what they're doing and is using it, you can ensure that what > you're advertising actually exists. [...] You misunderstood - I am not talking about whether the variables exist in the context of the source code. The question is which of those variables still exist, live & addressable, in the machine code and execution state. You may be surprised to what extent compiler optimizations disrupt a simple source-level reading of the situation. > > 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. > > Yes there are. There are actually two performance impacts: > > 1. The nops themselves take cycles to execute ... small, granted, > but it adds up with lots of probe points > 2. The probes interfere with optimisation since to replace them > with a function call, they must be barriers. [...] That's why I qualified it with "tangible". Please confirm your intuition about these costs. - FChE