From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
Date: Thu, 17 Jul 2014 18:10:58 +0100 [thread overview]
Message-ID: <20140717171058.GM18203@arm.com> (raw)
In-Reply-To: <CAFEAcA_ZXDDRycNVXmw1FSgRFiPgtB_2qqe-ioj91jMeBJR7PQ@mail.gmail.com>
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
It basically means that Linux would not rely on the user space to make
informed decisions on where to run a thread and avoid SIGILL.
--
Catalin
next prev parent reply other threads:[~2014-07-17 17:10 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 [this message]
2014-07-17 17:28 ` Will Deacon
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=20140717171058.GM18203@arm.com \
--to=catalin.marinas@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.