Messages in this thread |  | | Date | Tue, 10 Oct 2000 07:23:54 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: Calling current() from interrupt context |
| |
"Jeff V. Merkey" wrote: > > "Jeff V. Merkey" wrote: > > > > "David S. Miller" wrote: > > > > > > Date: Tue, 10 Oct 2000 00:44:58 +0200 > > > From: "Andi Kleen" <ak@suse.de> > > > > > > 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 get really slow, I/O performance go down 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. The other methods are slower. > > > > this is how it's done in NetWare and MANOS. It works.... > > > > :-) > > > > Jeff > > > > > > > > Later, > > > David S. Miller > > > davem@redhat.com > > > - > > > 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/ - 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/
|  |