Re: [PATCH/RFC v1 0/2] Human readable performance eventdescription in sysfs

From: Russell King - ARM Linux
Date: Wed Jan 20 2010 - 11:36:27 EST


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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/