All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
Date: Thu, 17 Jul 2014 18:28:58 +0100	[thread overview]
Message-ID: <20140717172858.GD4844@arm.com> (raw)
In-Reply-To: <20140717171058.GM18203@arm.com>

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

Will

  reply	other threads:[~2014-07-17 17:28 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 15:32 [PATCHv4 0/5] arm64: handle heterogeneous system register values Mark Rutland
2014-07-16 15:32 ` [PATCHv4 1/5] arm64: add MIDR_EL1 field accessors Mark Rutland
2014-07-16 15:32 ` [PATCHv4 2/5] arm64: cpuinfo: record cpu system register values Mark Rutland
2014-07-16 15:32 ` [PATCHv4 3/5] arm64: cachetype: report weakest cache policy Mark Rutland
2014-07-16 15:32 ` [PATCHv4 4/5] arm64: add runtime system sanity checks Mark Rutland
2014-07-16 15:32 ` [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs Mark Rutland
2014-07-16 15:57   ` Will Deacon
2014-07-17 10:30     ` Catalin Marinas
2014-07-17 10:39     ` Peter Maydell
2014-07-17 10:46       ` Marcus Shawcroft
2014-07-17 10:54         ` Will Deacon
2014-07-17 11:09           ` Ard Biesheuvel
2014-07-17 11:12           ` Peter Maydell
2014-07-17 12:35             ` Will Deacon
2014-07-17 13:55               ` Peter Maydell
2014-07-17 17:10                 ` Catalin Marinas
2014-07-17 17:28                   ` Will Deacon [this message]
2014-07-18  9:27                     ` Catalin Marinas
2014-07-18  9:53                       ` Will Deacon
2014-07-18 13:57                         ` Mark Rutland
2014-07-18 15:52                           ` Peter Maydell
2014-07-18 15:58                             ` Mark Rutland
2014-07-18 16:18                               ` Peter Maydell
2014-07-18 16:41                                 ` Mark Rutland
2014-07-18 20:24                                   ` Christopher Covington
2014-07-16 15:55 ` [PATCHv4 0/5] arm64: handle heterogeneous system register values Will Deacon
2014-07-17 11:03 ` Catalin Marinas
2014-07-17 14:21   ` Mark Rutland
2014-07-17 14:28     ` Will Deacon

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 \
    --in-reply-to=20140717172858.GD4844@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.