From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Jamie Lokier <jamie@shareable.org>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
jpihet@mvista.com, p.osciak@samsung.com,
"Jamie Iles" <jamie.iles@picochip.com>,
will.deacon@arm.com,
"Michał Nazarewicz" <m.nazarewicz@samsung.com>,
linux-kernel@vger.kernel.org, kyungmin.park@samsung.com,
mingo@elte.hu, "Tomasz Fujak" <t.fujak@samsung.com>,
linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com
Subject: Re: [PATCH/RFC v1 0/2] Human readable performance event description in sysfs
Date: Wed, 20 Jan 2010 16:35:25 +0000 [thread overview]
Message-ID: <20100120163525.GE27507@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20100120162647.GB7348@shareable.org>
On Wed, Jan 20, 2010 at 04:26:47PM +0000, Jamie Lokier wrote:
> In practice, the list of capabilities works well on x86 in /proc/cpuinfo:
>
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor vmx est tm2 xtpr pdcm
>
> They are based on the feature bits from the CPU's cpuid instruction,
> but the kernel does things like apply errata quirks to remove bits
> that don't work on a particular implementation and show the lowest common
> denominator when there are multiple CPUs.
You're assuming that there's a fixed set of feature bits on ARM. There
aren't.
What you have is a main ID register up until ARMv6, which has about
four different encodings. On some CPUs, this is the only ID register
offered, and within that subset, some different CPUs (eg, implemented
by different manufacturers, or indeed the same manufacturer) have the
same ID register value, despite being rather different.
>From ARMv6k and later, we have a different ID scheme, where we have
about 10 32-bit registers giving detailed information about various
aspects of the CPU - including five 32-bit registers for details about
the instruction set.
We know that some of the meanings of these registers has changed their
meaning - and I don't think there's a way to identify which meaning
should be applied to the registers (it seems to require reading lots
of different documents to sort out what CPUs implement which method.)
Frankly, it's a mess, and when you look at implementations, it turns out
to be unreliable.
> On ARM, it would be great to have a simple set of features in
> /proc/cpuinfo indicating which instruction sets are available (and
> reliable).
I think you've living in a dream world there.
next prev parent reply other threads:[~2010-01-20 16:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 9:11 Tomasz Fujak
2010-01-20 9:11 ` [PATCH v1 1/2] perfevent: Add performance event structure definition and 'extevents' sysfs entry Tomasz Fujak
2010-01-20 9:11 ` [PATCH v1 2/2] [ARM] perfevent: Event description list for ARMv6, Cortex-A8 and Cortex-A9 exported Tomasz Fujak
2010-01-20 9:16 ` [PATCH/RFC v1 0/2] Human readable performance event description in sysfs Peter Zijlstra
2010-01-20 9:46 ` Tomasz Fujak
2010-01-20 9:57 ` Michał Nazarewicz
2010-01-20 13:31 ` Jamie Iles
2010-01-20 13:39 ` Peter Zijlstra
2010-01-20 13:55 ` Russell King - ARM Linux
2010-01-20 14:01 ` Peter Zijlstra
2010-01-20 14:09 ` Michał Nazarewicz
2010-01-20 14:16 ` Peter Zijlstra
2010-01-20 14:26 ` Peter Zijlstra
2010-01-20 14:45 ` Russell King - ARM Linux
2010-01-20 14:54 ` Michał Nazarewicz
2010-01-20 14:41 ` Russell King - ARM Linux
2010-01-20 15:03 ` Jamie Iles
2010-01-20 15:42 ` Russell King - ARM Linux
2010-01-20 16:18 ` Jamie Iles
2010-01-20 16:26 ` Jamie Lokier
2010-01-20 16:35 ` Russell King - ARM Linux [this message]
2010-01-20 9:57 ` Russell King - ARM Linux
2010-01-20 10:21 ` Tomasz Fujak
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=20100120163525.GE27507@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=jamie.iles@picochip.com \
--cc=jamie@shareable.org \
--cc=jpihet@mvista.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.nazarewicz@samsung.com \
--cc=m.szyprowski@samsung.com \
--cc=mingo@elte.hu \
--cc=p.osciak@samsung.com \
--cc=peterz@infradead.org \
--cc=t.fujak@samsung.com \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®