* Frederic Weisbecker (fweisbec@gmail.com) wrote:
quoted text
> 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.
;)

quoted text
> 
> 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.

quoted text
> 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

quoted text
> 
> Thanks.
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/