Re: [PATCH] tracing: Cleanup the convoluted softirq tracepoints

[Thomas Gleixner]

On Tue, 19 Oct 2010, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 23:07 +0200, Thomas Gleixner wrote:
> > 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   $0x0,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?
> 
> > 
> > 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.
> 
> > 
> > In case the trace point is disabled the jmpq is noped out, so it jumps
> > to 72 directly.
> 
> That is correct.
> 
> > 
> > > 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?
> 
> > 
> > > 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.

Crap, crap, crap. This has nothing to do with the arguments of that
trace point, it's a compiler problem and you are just hoping that GCC
will do the right thing.

That's the complete wrong assumption and as Jason confirmed GCC is not
up to it at all.

hpa just posted code which does the _RIGHT_ _THING_ independent of any
compiler madness and you tracer folks just missed it.

Your jump label optimization made code even worse for todays common
compilers. Just admit it and fix that mess you created or simply
disable it.

Thanks,

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