From: Jon Masters <email@example.com> To: Russell King - ARM Linux <firstname.lastname@example.org>, Jon Mason <email@example.com> Cc: firstname.lastname@example.org, email@example.com Subject: Re: [RFC 0/1] ARM: print MHz in /proc/cpuinfo Date: Sat, 2 Jul 2016 19:58:00 -0400 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20160607221809.GP1041@n2100.armlinux.org.uk> Hi Russell, Jon, On 06/07/2016 06:18 PM, Russell King - ARM Linux wrote: > On Tue, Jun 07, 2016 at 05:08:32PM -0400, Jon Mason wrote: >> Many users (and some applications) are expecting the CPU clock speed to >> be output in /proc/cpuinfo (as is done in x86, avr32, c6x, tile, parisc, >> ia64, and xtensa). > > Such as what applications? This is just another meaningless number, > which is just as meaningless as the bogomips number. It tells you > nothing really about the CPU which should remotely be used for > anything other than user display. It certainly can't be used for > algorithmic selection. Agreed. HOWEVER... We'll be coming back to add this for servers soon enough. It's on the todo, we just need a nice way to extract this information (as has been discussed). That's likely to be through DMI data or an ACPI addition that will be required and mandatory at some future point. > We have resisted publishing this information for years because not > every ARM CPU is capable of providing this information - for many, we > don't know what the CPU clock rate even is. I believe it is a mistake > to publish this information. There are two specific problems on ARM servers: 1). Idiots. I've seen many situations in which benchmarks were run on pre-production machines (often explicitly against legal agreements, but those never happened within my organization so that's their problem - this is carefully prohibited activity within our own walls and I make sure our guys never run any numbers on pre-production stuff just so it could never get into the "wrong" hands by accident...). What these idiots do is then spread rumors that ARM server X "sucks" because they ran a prohibited benchmark against a downclocked core and forgot how to multiply numbers together. It gets worse. But usually it's because they ran "cat /proc/cpuinfo" and it didn't tell them anything useful, so they used whatever they thought the frequency was supposed to be. These idiots include journalists. If you read the press, you'll see the Gandhi sequence is playing out already between one of the established vendors and an ARM vendor in which said established vendor is at the laughing/fighting stage of things. And in a couple of cases recently, the press included "we didn't know how fast it ran because /proc/cpuinfo didn't tell us anything, so we guessed". 2). Users. Those who use and admin servers get the "speed" from /proc/cpuinfo. It's a marketing number. It's useless. It absolutely must be provided to the user or administrator exactly like on x86. > If userspace wants to select an algorithm, > that needs to be done according to much more information than just the > CPU speed - it needs knowledge of the instruction timings as well, cache > behaviour, etc, and you might as well benchmark an implementation and > select at run time, caching the result. > > Since we've never exported this information, it's not a regression > and it's not part of the kernels standard API. Agreed. But we'll still be coming back to ensure this information is presented to users. I pointed out to ARM about 3-4 years ago that this was going to bite us. It is now biting us, and we will ensure that useless data is provided where it is on x86 for identical experience by users. That is unless or until x86 users do something else always. Our (separate) case will use DMI or ACPI for the same kind of data. Jon.
next prev parent reply other threads:[~2016-07-02 23:58 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-07 21:08 Jon Mason 2016-06-07 21:08 ` [RFC 1/1] " Jon Mason 2016-06-08 8:34 ` Sudeep Holla 2016-06-08 19:31 ` Jon Mason 2016-06-09 9:09 ` Sudeep Holla 2016-06-09 17:36 ` Jon Mason 2016-06-07 22:18 ` [RFC 0/1] " Russell King - ARM Linux 2016-06-07 22:58 ` Jon Mason 2016-07-02 23:58 ` Jon Masters [this message] 2016-07-03 16:54 ` Russell King - ARM Linux 2016-07-03 18:49 ` Andrew Lunn 2016-07-03 19:10 ` Russell King - ARM Linux 2016-07-18 10:02 ` Pavel Machek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC 0/1] ARM: print MHz in /proc/cpuinfo' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).