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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
