From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20050 invoked by alias); 10 Jul 2008 15:57:52 -0000 Received: (qmail 20042 invoked by uid 22791); 10 Jul 2008 15:57:51 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org 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 15:57:25 +0000 Received: from localhost (localhost [127.0.0.1]) by accolon.hansenpartnership.com (Postfix) with ESMTP id 7B3B6828D; Thu, 10 Jul 2008 10:57:20 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1215705441; bh=+DPdpJbfIfFU8jY6lWCwTcHubBemcMzd4Ck1ro/UEA 8=; l=2328; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=F7nnrq23SduIXWpNhysST8t4yQ748R052paRg 76RtkTdEN058wFEkl5IevO0ie4TlEMJw5jgdoKlVyc0cNEFPIGtw8IcPf9l7imIEduh D2AfAOBaWeU2iXG5ktnq9p+q4SROjRanFE1TZro4YIYVy0pk8BanBwW4DX++axEQajw = 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 jcXTLRNvjFUe; Thu, 10 Jul 2008 10:57: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 4132C802B; Thu, 10 Jul 2008 10:57:18 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1215705438; bh=+DPdpJbfIfFU8jY6lWCwTcHubBemcMzd4Ck1ro/UEA 8=; l=2328; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=a6cxygklS6aU8n8fSPnZp19XDcQMumSy8CgIo s6auCxYjzKrFa6FoA+m7YNa1s6eLF/twTM8GsCErM/OfVkonahJ6uWkCt8gHSpYi74i KWtgy1fIQZlb2AxPpyJtxU+yfuOvhMwqcDJUKGBk5k1b+rSwGkhdY2ChtPVX4vyrROE = Subject: Re: [RFC] simple dprobe like markers for the kernel From: James Bottomley To: Theodore Tso Cc: "Frank Ch. Eigler" , linux-kernel , systemtap@sourceware.org In-Reply-To: <20080710153017.GB25939@mit.edu> References: <1215638551.3444.39.camel__22002.9595810503$1215638656$gmane$org@localhost.localdomain> <1215697794.3353.5.camel@localhost.localdomain> <20080710142208.GC1213@redhat.com> <1215700996.3353.30.camel@localhost.localdomain> <20080710153017.GB25939@mit.edu> Content-Type: text/plain Date: Thu, 10 Jul 2008 15:57:00 -0000 Message-Id: <1215705437.3353.63.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/msg00127.txt.bz2 On Thu, 2008-07-10 at 11:30 -0400, Theodore Tso wrote: > On Thu, Jul 10, 2008 at 09:43:16AM -0500, James Bottomley wrote: > > 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 as I understand things, your light-weight tracepoints are designed > for very performance-sensitive code paths where we don't want to > disturbe the optimization in the deactivated state. In > non-performance sensitive parts of the kernel, where cycle counting is > not so important, tracepoints can and probably should still be used. > So I don't think you were proposing eliminating the current kernel > markers in favor of this approach, yes? That's right ... I started from the position that the current markers were too heavy for an I/O subsystem, but I'm sure they have many other uses. > When you said a tool could determine if the tracepoint had gotten > optimized away, or the variables were no longer present, I assume you > meant at compile time, right? Yes and no. Yes because a tool will be able to detect the problems, but no if you're thinking an actual kernel compile would do it (unless some tool is designed for this and integrated into the build ... the obvious tool is systemtap, but that might cause some heartburn). > So with the right tool built into the > kbuild infrastructure, if we could simply print warnings when > tracepoints had gotten optimized away, that would make the your simple > tracepoints quite safe for general use, I would think. Yes ... but someone has to come up with the tool. I suppose rebuilding the line number matrix and finding the variables at the location is easy mechanical dwarf stuff ... but it will give the kernel build a lot of external dependencies it didn't have before. Plus, this level of checking can only be done if dwarf is generated (i.e. CONFIG_KERNEL_DEBUG_INFO is y). James