Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932375AbbKYFpY (ORCPT ); Wed, 25 Nov 2015 00:45:24 -0500 Received: from edison.jonmasters.org ([173.255.233.168]:45573 "EHLO edison.jonmasters.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932122AbbKYFpU (ORCPT ); Wed, 25 Nov 2015 00:45:20 -0500 Message-ID: <56554AE9.5070901@jonmasters.org> Date: Wed, 25 Nov 2015 00:45:13 -0500 From: Jon Masters User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yang Shi , Will.Deacon@arm.com, Catalin.Marinas@arm.com CC: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linaro-kernel@lists.linaro.org References: <1447870505-19319-1-git-send-email-yang.shi@linaro.org> In-Reply-To: <1447870505-19319-1-git-send-email-yang.shi@linaro.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 74.92.29.237 X-SA-Exim-Mail-From: jcm@jonmasters.org Subject: Re: [PATCH] arm64: restore bogomips information in /proc/cpuinfo X-SA-Exim-Version: 4.2.1 (built Sun, 08 Nov 2009 07:31:22 +0000) X-SA-Exim-Scanned: Yes (on edison.jonmasters.org) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1821 Lines: 37 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. Whether we do this through one of the platform tables or otherwise (multiple vendor EFI firmwares are being modified to make this much more glaringly obvious in the GUI view of system configuration so that when they do things they shouldn't, it's at least in the output) we should ultimately make sure that idiots at least have a fighting chance of noticing that they're actually running at 1GHz, and not 2 or 3GHz. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/