From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753509AbdJTRYb (ORCPT ); Fri, 20 Oct 2017 13:24:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54326 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753131AbdJTRY3 (ORCPT ); Fri, 20 Oct 2017 13:24:29 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9E3AB8210B Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jcm@redhat.com Subject: Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable To: Mark Rutland , Al Stone References: <20170926222324.17409-1-ahs3@redhat.com> <20170927103406.GC32150@leverpostej> <20171013142724.GA5893@leverpostej> <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> Cc: Timur Tabi , "linux-arm-kernel@lists.infradead.org" , lkml , rruigrok@codeaurora.org From: Jon Masters Message-ID: Date: Fri, 20 Oct 2017 13:24:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 20 Oct 2017 17:24:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On 10/20/2017 12:10 PM, Mark Rutland wrote: > On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote: >> Obviously, you'll have to see the patches to >> properly answer that, but what I'm playing with at present is placing >> this info in new entries in /sys/devices/cpu and/or /sys/devices/system, >> and generating some of the content based on what's already in header files >> (e.g., in cputype.h). > > My opposition to MIDR -> string mapping applies regardless of > location... Well, we do need to have the name to display to the user. Two things that absolutely need to be in a clear, easy to find place: 1). The make and model of the CPU in human readable format 2). The nominal and operating frequency of the CPU(s) Obviously, I want this to be in /proc/cpuinfo, but if it goes elsewhere (and other arches get behind it), then that could work. For the mapping of name to model, I agree that hard coding stuff in the kernel is ugly. This means that we need to either leverage DMI/SMBIOS data or add a new API to something like PSCI (ugly, maybe dangerous) to get the info. Here are some reasons that I care: 1). The first thing people do when they get an Arm server is to cat /proc/cpuinfo. They then come complaining that it's not like x86. They can't get the output their looking for and this results in bug filing, and countless hours on phone calls discussing over and over again. Worse, there are some parts of the stack that really need this. 2). I have seen entire Arm server SoCs get a bad review because the person running some test couldn't get the frequency reported in a sensible enough place that they noticed it was an early part clocked at half the frequency. Today, they have little opportunity to notice the frequency and a lot of chance to start spreading rumors that some part "sucks". Sure, bogomips, other numbers are all lies. But if I had a penny for every time someone said "man, this server only runs at 100/400 MHz! that's so slow!" (arch timer) So we're going to clean this up. I've spoken with all of the vendors and there's general agreement that this needs changing for Enterprise users. But how it's done - definitely there's flexibility there. One thing that we won't do is have no solution. While it would be very unfortunate to carry something just in RHEL, we'll do it (hopefully in collaboration with other distros) if this isn't resolvable upstream. Thanks, Jon. -- Computer Architect | Sent from my Fedora powered laptop From mboxrd@z Thu Jan 1 00:00:00 1970 From: jcm@redhat.com (Jon Masters) Date: Fri, 20 Oct 2017 13:24:25 -0400 Subject: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable In-Reply-To: <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> References: <20170926222324.17409-1-ahs3@redhat.com> <20170927103406.GC32150@leverpostej> <20171013142724.GA5893@leverpostej> <20171020161053.ujw3spzizhgu4g7b@lakrids.cambridge.arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Mark, On 10/20/2017 12:10 PM, Mark Rutland wrote: > On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote: >> Obviously, you'll have to see the patches to >> properly answer that, but what I'm playing with at present is placing >> this info in new entries in /sys/devices/cpu and/or /sys/devices/system, >> and generating some of the content based on what's already in header files >> (e.g., in cputype.h). > > My opposition to MIDR -> string mapping applies regardless of > location... Well, we do need to have the name to display to the user. Two things that absolutely need to be in a clear, easy to find place: 1). The make and model of the CPU in human readable format 2). The nominal and operating frequency of the CPU(s) Obviously, I want this to be in /proc/cpuinfo, but if it goes elsewhere (and other arches get behind it), then that could work. For the mapping of name to model, I agree that hard coding stuff in the kernel is ugly. This means that we need to either leverage DMI/SMBIOS data or add a new API to something like PSCI (ugly, maybe dangerous) to get the info. Here are some reasons that I care: 1). The first thing people do when they get an Arm server is to cat /proc/cpuinfo. They then come complaining that it's not like x86. They can't get the output their looking for and this results in bug filing, and countless hours on phone calls discussing over and over again. Worse, there are some parts of the stack that really need this. 2). I have seen entire Arm server SoCs get a bad review because the person running some test couldn't get the frequency reported in a sensible enough place that they noticed it was an early part clocked at half the frequency. Today, they have little opportunity to notice the frequency and a lot of chance to start spreading rumors that some part "sucks". Sure, bogomips, other numbers are all lies. But if I had a penny for every time someone said "man, this server only runs at 100/400 MHz! that's so slow!" (arch timer) So we're going to clean this up. I've spoken with all of the vendors and there's general agreement that this needs changing for Enterprise users. But how it's done - definitely there's flexibility there. One thing that we won't do is have no solution. While it would be very unfortunate to carry something just in RHEL, we'll do it (hopefully in collaboration with other distros) if this isn't resolvable upstream. Thanks, Jon. -- Computer Architect | Sent from my Fedora powered laptop