On Tue, 2010-10-19 at 23:07 +0200, Thomas Gleixner wrote:
quoted text
> On Tue, 19 Oct 2010, Steven Rostedt wrote:
> > On Tue, 2010-10-19 at 21:49 +0200, Thomas Gleixner wrote:
> > > So that saves _TWO_ bytes of text and replaces:
> > > 
> > > -  1e:	83 3d 00 00 00 00 00 	cmpl   __PLACEHOLDER__0_x0,0x0(%rip)        # 25 <test+0x25>
> > > -  25:	74 4d                	je     74 <test+0x74>
> > > +  1e:	e9 00 00 00 00       	jmpq   23 <test+0x23>
> > > +  23:	eb 4d                	jmp    72 <test+0x72>
> > > 
> > > So it trades a conditional vs. two jumps ? WTF ??
> > 
> > Well, the one jmpq is noped out, and the jmp is non conditional. I've
> 
> What are you smoking ?

What? Are you saying that conditional jumps are just as fast as non
conditional ones?

quoted text
> 
> In case the trace point is enabled the jmpq is there, so it jumps to
> 23 and jumps from there to 72.

No, when we dynamically enable the tracepoint, it will jump to 25, not
23. That's what the goto part is about. We add the do_trace label to the
table, and we make it point to that location. If we did it as you say,
then tracepoints would never be enabled.

This is not unlike what we do with the function tracer. The original
code points to mcount which simply is:

	mcount:
		retq

And when we enable the callers, we have it jump to a different function.

quoted text
> 
> In case the trace point is disabled the jmpq is noped out, so it jumps
> to 72 directly.

That is correct.

quoted text
> 
> > always thought a non conditional jmp was faster than a conditional one,
> 
> I always thought, that at least some of the stuff which comes from
> tracing folks makes some sense.

Is it still not making sense?

quoted text
> 
> > since there's no need to go into the branch prediction logic. The CPU
> > can simply skip to the code to jump next. Of counse, this pollutes the 
> > I$.
> 
> We might consult Mathieu for further useless blurb on how CPUs work
> around broken code.

The code worked fine before, it just was not very pretty.

But it seemed that gcc for you inlined the code in the wrong spot.
Perhaps it's not a good idea to have the something like h - softirq_vec
in the parameter of the tracepoint. Not saying that your change is not
worth it. It is, because h - softirq_vec is used by others now too.


-- Steve


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