linux-kernel - Re: [PATCH v7 04/17] tracing: add static function tracer support for MIPS

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:	Wed, 11 Nov 2009 14:18:15 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Wu Zhangjin <wuzhangjin@...il.com>
cc:	David Daney <ddaney@...iumnetworks.com>, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org, zhangfx@...ote.com, zhouqg@...il.com,
	Ralf Baechle <ralf@...ux-mips.org>, rostedt@...dmis.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Nicholas Mc Guire <der.herr@...r.at>,
	Richard Sandiford <rdsandiford@...glemail.com>,
	Patrik Kluba <kpajko79@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Michal Simek <monstr@...str.eu>
Subject: Re: [PATCH v7 04/17] tracing: add static function tracer support
 for MIPS

On Wed, 11 Nov 2009, Wu Zhangjin wrote:

> >  No, register jumps cannot be predicted -- this is where the performance 
> > goes on any serious processor -- the two extra instructions are nothing 
> > compared to that.  OTOH frame pointer calculations are pure arithmetic, so 
> > you only lose time incurred by the instructions themselves.
> 
> Yes, I only mean the -mlong-calls and the original -mno-long-calls with
> -pg.
> 
> The orignal one looks like this:
> 
> move ra, at
> jal _mcount
> 
> The new one with -mlong-calls looks like this:
> 
> lui v1, HI_16BIT_OF_MCOUNT
> addiu v1, v1, LOW_16BIT_OF_MCOUNT
> move ra, at
> jalr v1
> 
> both of them have a "jump" instruciton, so, only two lui, addiu added
> for -mlong-calls ;)
> 
> what about the difference between that "jal _mcount"  and "jalr v1"?

 As I say, the latter cannot be predicted and will incur a stall for any 
decent pipeline.  With the former the target address of the jump can be 
calculated early and the instruction fetch unit can start feeding 
instructions from there into the pipeline even before the jump has reached 
the execution stage.

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