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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.20.1511250958370.22569@knanqh.ubzr>
Date:	Wed, 25 Nov 2015 10:16:02 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Jon Masters <jcm@...masters.org>
cc:	Yang Shi <yang.shi@...aro.org>, Will.Deacon@....com,
	Catalin.Marinas@....com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org
Subject: Re: [PATCH] arm64: restore bogomips information in /proc/cpuinfo

On Wed, 25 Nov 2015, Jon Masters wrote:

> On 11/18/15, 1:15 PM, Yang Shi wrote:
> 
> > As what Pavel Machek reported [1], some userspace applications depend on
> > bogomips showed by /proc/cpuinfo.
> >
> > Although there is much less legacy impact on aarch64 than arm, but it does
> > break libvirt.
> >
> > Basically, this patch reverts commit
> > 326b16db9f69fd0d279be873c6c00f88c0a4aad5
> > ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo"), but with
> > some tweak due to context change.
> 
> On a total tangent, it would be ideal to (eventually) have something reported
> in /proc/cpuinfo or dmesg during boot that does "accurately" map back to the
> underlying core frequency (as opposed to the generic timer frequency). I have
> seen almost countless silly situations in the industry (external to my own
> organization) in which someone has taken a $VENDOR_X reference system that
> they're not supposed to run benchmarks on, and they've done it anyway. But
> usually on some silicon that's clocked multiples under what production would
> be. Then silly rumors about performance get around because nobody can do
> simple arithmetic and notice that they ought to have at least divided by some
> factor.

Be my guest my friend.

According to the common wisdom, the bogomips reporting is completely 
senseless at this point and no one should expect anything useful from 
it. Therefore I attempted to rehabilitate some meaning into it given 
that we just can't get rid of it either and it continues to cause 
dammage. You certainly saw where that has led me.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ