From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Fri, 18 Jul 2014 10:53:12 +0100 Subject: [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs In-Reply-To: <20140718092744.GA19850@arm.com> References: <20140716155747.GR29414@arm.com> <53C7A980.8050601@arm.com> <20140717105415.GI21153@arm.com> <20140717123533.GJ21153@arm.com> <20140717171058.GM18203@arm.com> <20140717172858.GD4844@arm.com> <20140718092744.GA19850@arm.com> Message-ID: <20140718095311.GA1818@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Jul 18, 2014 at 10:27:44AM +0100, Catalin Marinas wrote: > On Thu, Jul 17, 2014 at 06:28:58PM +0100, Will Deacon wrote: > > On Thu, Jul 17, 2014 at 06:10:58PM +0100, Catalin Marinas wrote: > > > On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote: > > > > On 17 July 2014 13:35, Will Deacon wrote: > > > > > We're not denying the possibility of heterogeneity, we're trying to expose a > > > > > consistent view of the system to userspace. Differences between cores should > > > > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly > > > > > passed off to userspace. > > > > > > > > On that basis, why report anything at all about invididual cores? > > > > Just have /proc/cpuinfo report "number of processors: 4" and > > > > no per-CPU information at all... > > > > > > We lost a lot of time on this already (given the internal threads). So > > > my proposal is to go ahead with Mark's patch with per-CPU features. They > > > currently just include the same elf_hwcap multiple times. If we ever > > > need to present different features, the conditions would be: > > > > > > 1. Never report more than elf_hwcap > > > 2. elf_hwcap can only include non-symmetric features *if* Linux gets a > > > way to transparently handle migration or emulation > > > > ... making the point of a per-cpu field entirely pointless ;) > > Well, if we can support such features in a transparent way, > /proc/cpuinfo becomes more informative (e.g. user wondering why a > process runs only on certain CPUs). > > But to be clear (and I think we are aligned), I don't trust user space > to parse all processors in /proc/cpuinfo and make an informed selection > of CPU affinity to avoid SIGILL. > > Yet another option would be to have a single features/hwcap line and > present the extra features in a human (and only human) readable form > (e.g. some haiku that changes with every kernel release ;)). Or just have the single features line, then the per-cpu line can be called `flags' or something, like Ard suggested. If userspace decides to parse flags, it deserves all the pain that it gets. Will