linux-kernel - Re: [PATCH] tracing: Cleanup the convoluted softirq tracepoints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Oct 2010 17:23:59 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Koki Sanagi <sanagi.koki@...fujitsu.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	nhorman@...driver.com, scott.a.mcmillan@...el.com,
	laijs@...fujitsu.com, "H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, eric.dumazet@...il.com,
	kaneshige.kenji@...fujitsu.com, David Miller <davem@...emloft.net>,
	izumi.taku@...fujitsu.com, kosaki.motohiro@...fujitsu.com,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	"Luck, Tony" <tony.luck@...el.com>
Subject: Re: [PATCH] tracing: Cleanup the convoluted softirq tracepoints

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.


-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/