linux-kernel - Re: [PATCH 1/3] [ARM] Translate delay.S into (mostly) C

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:	Thu, 07 Oct 2010 17:11:06 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Nicolas Pitre <nico@...xnic.net>
CC:	Daniel Walker <dwalker@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	Kevin Hilman <khilman@...prootsystems.com>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Saravana Kannan <skannan@...eaurora.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Colin Cross <ccross@...roid.com>,
	linux-arm-kernel@...ts.infradead.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/3] [ARM] Translate delay.S into (mostly) C

 On 10/06/2010 01:05 PM, Nicolas Pitre wrote:
> You could use the noinline qualifier from <linux/compiler.h> with those 
> functions you don't want inlined.
>

That won't help me for the interleaving behavior though.

>> Is it possible to do all this in assembly ? Can't you have the default
>> implementation using this assembly with different function names, then
>> just set the assembly function names in C code someplace?
> That weould be my preference too.  Being in assembly means that this 
> code is unlikely to change with different optimization levels and/or gcc 
> versions which would otherwise require different calibration values. 
> Relying on stable calibration is necessary for the lpj kernel cmdline 
> parameter to have some meaning.

Why doesn't any other architecture use assembly for their lpj code? They
may use headers with assembly in them or C code with assembly in them,
but they don't write all of the delay code in assembly and rely on
function interleaving. This leads me to believe other arches aren't
concerned about compiler optimizations breaking lpj cmdline parameters,
so why should ARM be concerned?

I tested the theory out and scaled down the CPU frequency to 19.2 MHz
and then called calibrate_delay(). Before and after applying this series
I got the same results.

Calibrating delay loop... 12.67 BogoMIPS (lpj=63360)

Jumping up to 1.2 GHz and calling calibrate_delay() gives me the same
before and after

Calibrating delay loop... 792.98 BogoMIPS (lpj=3964928)

I don't have access to a machine capable of running slower than 19.2
MHz. Maybe machines running in the KHz range would experience differences?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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