"Jeff V. Merkey" wrote:
>
> "David S. Miller" wrote:
> >
> > Date: Tue, 10 Oct 2000 00:44:58 +0200
> > From: "Andi Kleen" <[EMAIL PROTECTED]>
> >
> > On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > > I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> > > behind an I/O interface that is slower than ideal
> >
> > Where would you put it for IA32 ? I don't know any free MSR that could
> > be abused for that, and acessing MSRs is insanely slow anyways. Any
> > other ideas ?
> >
> > The local APIC holds the hardware cpu number (which happens to equal
> > the logical cpu number in the current x86 code). And I believe the
> > local APIC has a 32-bit scratch register or 2 as well... but don't
> > quote me on that one.
>
> Accessing the CPUID from the local APIC is slower than mollasses. The
> reason for this is due to the fact that the APIC address ranges are
> treated as non-cacheable memory, and will always generate a
> non-cacheable memory reference when you read from the APIC_ID register
> and shift the ID.
You can verify this with a logic analyzer and watch the system suck wind
and get really slow, I/O performance go to shit after you read the
memory mapped APIC registers from a context
switch loop, i.e.
while (1)
{
read_local_apic(); // OINK OINK OINK -- bus utilitization will go
through the roof.
schedule()
}
and watch it oink...
>
> A simpler solution is to use the CR2 register to store the CPU number,
> and always reload the register after a page fault (since CR2 will hold a
> faulting address). THis is even better than Linus' stack based method
> for storing the number since you just are reading a register, which is
> fast as hell. The other methods are slower.
>
> hHis is how it's done in NetWare and MANOS. It works....
>
> :-)
>
> Jeff
>
> >
> > Later,
> > David S. Miller
> > [EMAIL PROTECTED]
> > -
> > 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/
-
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/
