From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757909Ab0JSVYE (ORCPT ); Tue, 19 Oct 2010 17:24:04 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:34258 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754605Ab0JSVYC (ORCPT ); Tue, 19 Oct 2010 17:24:02 -0400 X-Authority-Analysis: v=1.1 cv=6ptpMFIBtxRk0xdOb6IhJTbTLVRlKjWFes7R4SsWCrA= c=1 sm=0 a=wGm5nfgfXM4A:10 a=Q9fys5e9bTEA:10 a=OPBmh+XkhLl+Enan7BmTLg==:17 a=aWiL55X8w6u1j5gxG9sA:9 a=I2GFy4nwBvMqdmBUmbkA:7 a=bL7f-jgvgiYGFOkOmOdps_zUFhUA:4 a=PUjeQqilurYA:10 a=OPBmh+XkhLl+Enan7BmTLg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 67.242.120.143 Subject: Re: [PATCH] tracing: Cleanup the convoluted softirq tracepoints From: Steven Rostedt To: Thomas Gleixner Cc: Mathieu Desnoyers , Koki Sanagi , Peter Zijlstra , Ingo Molnar , Frederic Weisbecker , nhorman@tuxdriver.com, scott.a.mcmillan@intel.com, laijs@cn.fujitsu.com, "H. Peter Anvin" , LKML , eric.dumazet@gmail.com, kaneshige.kenji@jp.fujitsu.com, David Miller , izumi.taku@jp.fujitsu.com, kosaki.motohiro@jp.fujitsu.com, Heiko Carstens , "Luck, Tony" In-Reply-To: References: <20100908112529.GA25931@elte.hu> <1287395077.29097.1543.camel@twins> <1287398936.29097.1548.camel@twins> <4CBD79CF.2060706@jp.fujitsu.com> <20101019132236.GA19197@Krystal> <1287496495.16971.372.camel@gandalf.stny.rr.com> <20101019142820.GA14520@Krystal> <1287521757.16971.397.camel@gandalf.stny.rr.com> Content-Type: text/plain; charset="ISO-8859-15" Date: Tue, 19 Oct 2010 17:23:59 -0400 Message-ID: <1287523439.16971.433.camel@gandalf.stny.rr.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > - 25: 74 4d je 74 > > > + 1e: e9 00 00 00 00 jmpq 23 > > > + 23: eb 4d jmp 72 > > > > > > 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