From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752577Ab0CSCkq (ORCPT ); Thu, 18 Mar 2010 22:40:46 -0400 Received: from mail.openrapids.net ([64.15.138.104]:35920 "EHLO blackscsi.openrapids.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751153Ab0CSCkp (ORCPT ); Thu, 18 Mar 2010 22:40:45 -0400 Date: Thu, 18 Mar 2010 22:40:42 -0400 From: Mathieu Desnoyers To: Frederic Weisbecker Cc: Hitoshi Mitake , Jason Baron , Steven Rostedt , Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, h.mitake@gmail.com, Paul Mackerras , Arnaldo Carvalho de Melo , Jens Axboe Subject: Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock Message-ID: <20100319024042.GB28941@Krystal> References: <1268563128-6486-1-git-send-email-mitake@dcl.info.waseda.ac.jp> <1268590435.9440.8.camel@laptop> <20100317013236.GB5258@nowhere> <20100317095230.GD17146@elte.hu> <4BA1C141.8050409@dcl.info.waseda.ac.jp> <20100318211633.GG5103@nowhere> <20100319010857.GC23020@Krystal> <20100319012337.GA22095@nowhere> <20100319013658.GB28456@Krystal> <20100319022659.GC22095@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100319022659.GC22095@nowhere> X-Editor: vi X-Info: http://www.efficios.com X-Operating-System: Linux/2.6.26-2-686 (i686) X-Uptime: 22:34:27 up 55 days, 5:11, 7 users, load average: 0.31, 0.15, 0.10 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Frederic Weisbecker (fweisbec@gmail.com) wrote: > On Thu, Mar 18, 2010 at 09:36:58PM -0400, Mathieu Desnoyers wrote: > > * Frederic Weisbecker (fweisbec@gmail.com) wrote: > > > On Thu, Mar 18, 2010 at 09:08:57PM -0400, Mathieu Desnoyers wrote: > > > > > I sometimes wonder which trick between jmp optimization and hot patching > > > > > would be the best to optimize the tracepoints off-cases. > > > > > > > > > > I should look more closely at the jmp optimization. I don't know if > > > > > it avoids to push the tracepoints parameters in the off case, in > > > > > which case it could be perhaps more efficient than hot patching, > > > > > > > > yep, tracepoints with jump patching will branch over the whole stack setup in > > > > the off case, which is one of the good reasons for using this solution over > > > > patching only a call (leaving the stack setup in place). > > > > > > > > > > > > Ok that's good to know. It's a pretty good argument against hot > > > patching in this particular case. > > > > > > > > > > > > > Note that if the parameters include side-effects (such as a function call), > > > > these will be executed even when the tracepoint is disabled. This is why people > > > > should implement these calls with side-effects in the appropriate TRACE_EVENT > > > > fields. > > > > > > > > > Good to know too. > > > But this makes me curious. So it guarantees stack setup won't happen but > > > can't sort it out with functions as parameters or so? > > > > > > I have no idea how this thing works. Please Cc me for the next batch, > > > this looks like a cool thing :) > > > > > > > Well, the now deceased "Linux Kernel Markers" (which were based on a single > > macro rather than static inline functions) were able to use the preprocessor to > > put function calls passed as argument within the conditional branch. But with > > tracepoints, we rely on static inlines to have flexible parameter declaration, > > so this is not possible. > > > Ok. > > > > > All the arguments passed to the static inline (eventually used for the stack > > setup of the actual function call within the tracepoint) can be moved into the > > conditional branch by the compiler optimizations, because they are not needed > > otherwise. However, this cannot be done for function calls passed as parameter > > to the tracepoint, because the compiler do not know whether or not the function > > side-effects are needed outside of the "tracing active" branch. > > > > Mathieu > > > > Ok. I just read this: http://lwn.net/Articles/362752/ and > this: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html > > What is funky is that the gcc example takes this jmp/nop patching > as an example to explain asm goto, so it all looks clear to me now :-) Well, the use-case that drove the asm goto implementation _is_ the tracepoints. ;) > > But, looking at __DO_TRACE: > > if (it_func) { \ > do { \ > ((void(*)(proto))(*it_func))(args); \ > } while (*(++it_func)); \ > } > > I would expect the compiler not to load the parameters in the stack > before first checking the branch. Note that you have to put that in its full context. It's a macro expanded within a static inline function. The initial parameters are passed to the static inline, not directly as "args" here. So parameters with side-effects have to be evaluated before their result can be passed to the static inline function, so in that sense their evaluation cannot be moved into the conditional branch. > So, the fact that parameters are not loaded before we know we'll call > the tracepoint is something we already have or is it something that the jump > label brings in the package somehow? It's standard compiler optimization behavior. Thanks, Mathieu > > Thanks. > -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com