From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7409 invoked by alias); 10 Jul 2008 15:30:57 -0000 Received: (qmail 7393 invoked by uid 22791); 10 Jul 2008 15:30:57 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from www.church-of-our-saviour.org (HELO thunker.thunk.org) (69.25.196.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jul 2008 15:30:39 +0000 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1KGy66-0004U3-7N; Thu, 10 Jul 2008 11:30:18 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1KGy65-0002cl-KB; Thu, 10 Jul 2008 11:30:17 -0400 Date: Thu, 10 Jul 2008 15:30:00 -0000 From: Theodore Tso To: James Bottomley Cc: "Frank Ch. Eigler" , linux-kernel , systemtap@sourceware.org Bcc: tytso@mit.edu Subject: Re: [RFC] simple dprobe like markers for the kernel Message-ID: <20080710153017.GB25939@mit.edu> Mail-Followup-To: Theodore Tso , James Bottomley , "Frank Ch. Eigler" , linux-kernel , systemtap@sourceware.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1215700996.3353.30.camel@localhost.localdomain> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-IsSubscribed: yes 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/msg00126.txt.bz2 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? 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? 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. - Ted P.S. When you said that the current kernel markers are "a bit heavyweight", how bad are they in practice? Hundreds of cycles? More?