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

[Frederic Weisbecker]

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 :-)

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.
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?

Thanks.

--
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/