linux-kernel - Re: [PATCH] arm64: restore bogomips information in /proc/cpuinfo

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: <20151125120013.GJ8644@n2100.arm.linux.org.uk>
Date:	Wed, 25 Nov 2015 12:00:13 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jon Masters <jcm@...masters.org>
Cc:	Yang Shi <yang.shi@...aro.org>, Will.Deacon@....com,
	Catalin.Marinas@....com, linaro-kernel@...ts.linaro.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm64: restore bogomips information in /proc/cpuinfo

On Wed, Nov 25, 2015 at 12:45:13AM -0500, 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).

Absolutely not.  You need to read the discussion that we had with Linus
when someone reported that ARMs /proc/cpuinfo no longer reported it.

Linus says that Bogomips reports the calibration value for udelay(),
period.  Whether that's a software loop, or a hardware timer is neither
here nor there.  It's nothing to do with the CPU clock rate.

So, if your timer runs slowly, but your CPU is at the top end, a report
of 6 Bogomips is (as far as Linus is concerned) absolutely correct, and
we have no business at all as kernel developers coming up with some fake
or real value to make it report as the CPU clock rate.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/