linux-kernel - Re: [RFC PATCH 1/2] ARM: delay: print dummy values for bogomips

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]

Message-ID: <5188B8B2.5030601@arm.com>
Date:	Tue, 07 May 2013 09:17:54 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Pavel Machek <pavel@....cz>
CC:	Will Deacon <Will.Deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/2] ARM: delay: print dummy values for bogomips

On 07/05/13 00:16, Pavel Machek wrote:

Hi Pawel,

>> Now that we support a timer-backed delay loop, I'm quickly getting sick
>> and tired of people complaining that their beloved bogomips value has
>> decreased. You know who you are!
> 
>> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
>> will likely break fragile userspace code which is parsing that stuff, so
>> instead replace it with a dummy value that can be chosen in the
>> Kconfig.
> 
> So, instead of removing it you silently report invalid value? Note

Removing it would be an ABI breakage. Unfortunately.

> that there's no cpumhz display in procinfo... at least on OLPC I
> looked.

And? What does the CPU frequency bring you when any modern CPU has some
kind of cpufreq support that renders this information information pretty
much meaningless?

> And whether it is 30MHz or 3GHz cpu might be relevant information for
> userspace, and yes, bogomips used to be good enough for that.

Name one userspace application that extracts meaningful information out
of the BogoMIPS field. Just one.

> Actually it was mhz, mhz/2 or mhz*2 on pretty much all reasonable systems.

So any number within a ratio from one to four is good enough for you?
Wow. That pretty much proves the usefulness of this patch.

Additionally, having switched arch_timer capable CPUs to a timer based
delay instead of a loop-based delay means your precious pseudo-frequency
is now a thing of the past. And guess what? Nothing broke so far.
Because using BogoMIPS to deduct anything is *bogus*.

Timer-based delay calibration has been around for about ages. I still
remember the day (some 10 or 12 years ago) when DaveM switched the
UltraSPARC port to use the timer, and my BogoMIPS went from ~1000 to 12.
People moaned, DaveM held his position, and nothing happened. *Nothing*.
End of story.

	M.
-- 
Jazz is not dead. It just smells funny...

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