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

[Catalin Marinas]

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 ;)).

-- 
Catalin