Re: Error in x86 CPU capabilities starting with test5/6

[Mikael Pettersson <mikpe@csd.uu.se>]

Hmm, my CPUID vs /proc/cpuinfo comment seemed somewhat controversial.

Tigran Aivazian wrote:
 > Arguably, it is always better to parse /proc/cpuinfo instead of executing
 > CPUID directly (think PCI -- drivers should _NOT_ get their irq/io/etc
 > values from config space directly but only what the kernel puts on a plate
 > for them in the struct pci_dev).

In priciple I would agree, but CPUID is a lot easier to use than to open and
parse /proc/cpuinfo, specially when the format of the latter changes...

 > So, one could imagine the kernel which emulates in software some of the
 > processor features and then CPUID would lie but /proc/cpuinfo would tell
 > the truth.

In this case, I'd REALLY like to know whether the feature is emulated or not.
Imagine a kernel emulating MMX instructions, with a 10x performance loss.
My MPEG viewer has builtin support for MMX and non-MMX capable processors,
with the non-MMX version 2x slower. On a non-MMX processor, we'll still
be a lot better off using the non-MMX rendering libs.

In other cases it may not matter, only the user can tell.

Andi Kleen wrote:
 > The program would be broken if it executed CPUID itself, because it has no way to guarantee
 > that the CPUID is executed on all CPUs the scheduler may later move the task too.
 > ...
 > -Andi (proud owner of an AMP system with one CPU implementing FXSR and one not,
 > which causes lots of interesting problems) 

Yes, this is a problem. There are two alternatives:
- hpa's cpuid driver lets you execute cpuid on a specific processor
  (but it's an optional driver, so you can't count on it)
- Something like Solaris' processor_bind() which lets a user-space application
  "bind" itself to a given processor. AFAIK, Linux doesn't have this :-(

Alan Cox wrote:
 > It is not safe to use cpuid to check the availability of RDTSC in Linux because
 > the CPU itself does not know if the TSC is buggy (Some MediaGX, some WinChip,..)

User-space can also check vendor/family/mode/stepping values and choose not to
trust certain announced feature flags. No big deal.

 > or if the TSC on an SMP box is constant across all processors.

A recurring theme: asymmetric MP boxen :-(
Yeah, you and Andi are right, asymmetric MP boxen require kernel support.
I didn't consider that case...

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/