[PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs

[Will Deacon]

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 <will.deacon at arm.com> 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