Re: [PATCH RFC 00/11] lock monitor: Separate features related tolock

[Mathieu Desnoyers]

* Frederic Weisbecker (fweisbec@xxxxxxxxx) wrote:
> On Thu, Mar 18, 2010 at 09:36:58PM -0400, Mathieu Desnoyers wrote:
> > * Frederic Weisbecker (fweisbec@xxxxxxxxx) 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/