From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22954 invoked by alias); 10 Jul 2008 14:46:00 -0000 Received: (qmail 20910 invoked by uid 22791); 10 Jul 2008 14:44:21 -0000 X-Spam-Status: No, hits= required= tests= Received: from accolon.hansenpartnership.com (HELO accolon.hansenpartnership.com) (76.243.235.52) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jul 2008 14:43:24 +0000 Received: from localhost (localhost [127.0.0.1]) by accolon.hansenpartnership.com (Postfix) with ESMTP id 8D241828D; Thu, 10 Jul 2008 09:43:20 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1215701000; bh=GOEqVjC++Pc7y1nD2aWoaCuM5JjRqYL5HmgIU9RTqu 0=; l=5149; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=Kn/imgZmmzGvhffcWpnOOkGvlAgtTyol67Pct U+ic9JJnEVLgNGk2zl6mdoQ2I9rnn8G1FOZqRdghQClWFN9sUPCCIQfALKVNjiJUJoE PYW/u1VMx4ztVg6WLJ1um+noV5SfVuyYXBhQPoYNuxC+ojqbXfreZP6UUoU3vmBZPNE = Received: from accolon.hansenpartnership.com ([127.0.0.1]) by localhost (redscar.int.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwOnsY6bVxHG; Thu, 10 Jul 2008 09:43:18 -0500 (CDT) Received: from [153.66.150.222] (mulgrave-w.int.hansenpartnership.com [153.66.150.222]) by accolon.hansenpartnership.com (Postfix) with ESMTP id 5ABC6802B; Thu, 10 Jul 2008 09:43:17 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1215700997; bh=GOEqVjC++Pc7y1nD2aWoaCuM5JjRqYL5HmgIU9RTqu 0=; l=5149; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=g/4TqHnQErPV/7whQUgxX9JwQY4aM0GshsrAW Ha3YtNmvko+Ykbl1cutZ1hTEw5A3hBYx86B4zvPSrv/C4PFCWQyxh1GXA+ANT08/RA2 7NEUObPT5APQyabThZlQxs8uRkK68vOdRBuWKDVCT+ycTzltPlexTVuY8+YyLR3QZy0 = Subject: Re: [RFC] simple dprobe like markers for the kernel From: James Bottomley To: "Frank Ch. Eigler" Cc: linux-kernel , systemtap@sourceware.org In-Reply-To: <20080710142208.GC1213@redhat.com> References: <1215638551.3444.39.camel__22002.9595810503$1215638656$gmane$org@localhost.localdomain> <1215697794.3353.5.camel@localhost.localdomain> <20080710142208.GC1213@redhat.com> Content-Type: text/plain Date: Thu, 10 Jul 2008 14:46:00 -0000 Message-Id: <1215700996.3353.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit 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/msg00123.txt.bz2 On Thu, 2008-07-10 at 10:22 -0400, Frank Ch. Eigler wrote: > 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. That's what I'm actually already doing ... so far it works nicely. > 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. Not necessarily. A tracepoint by a barrier will always be pretty much OK, as will variables that are either passed in or passed to functions (since they have to be instantiated to pass as arguments). Plus screw ups are easily detectable by a tool that parses the dwarf. The essential point is that we need zero impact trace points and that makes them difficult to place in this fashion. However, the burden of placing and verifying them rests with the people in the actual subsystem (who are also the ones who hopefully get the most use out of them). > > > 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. Erm, no ... dwarf is designed to emit an entry for every line in the file (whether it contains a statment or not). The empty lines get elided in the line number program (because you can attach them to the first statement following) but a correct parser will recover them (by design in the dwarf). > > > 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. No ... I'm used to optimisation strangeness. Again, I'm not trying to eliminate it because that would defeat the zero impact purpose. I'm trying to build a system that can be useful without any impact. The consequence is going to be that certain trace points can't be used because of the optimiser, but that's the tradeoff. As long as the people placing the trace points are subject matter experts in the subsystem (and actually using them) everything should be OK. > > > 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. 1 is pretty obvious ... the nops have a defined cycle time in every instruction architecture. The optimisation costs are very difficult to quantify since they vary so much from compiler to compiler and function to function. James