lkml.org 
[lkml]   [2000]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Error in x86 CPU capabilities starting with test5/6
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/

\
 
 \ /
  Last update: 2005-03-22 12:47    [W:0.115 / U:5.420 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site