Messages in this thread |  | | | Date | Thu, 24 Nov 2005 04:23:59 +0100 (CET) | | From | Mikulas Patocka <> | | Subject | Re: [patch] SMP alternatives |
| |
On Wed, 23 Nov 2005, Alan Cox wrote:
> On Mer, 2005-11-23 at 10:42 -0800, Linus Torvalds wrote: >> Of course, if it's in one of the low 12 bits of %cr3, there would have to >> be a "enable this bit" in %cr4 or something. Historically, you could write >> any crap in the low bits, I think. > > There is a much much better way to do it than just user space and > without hitting cr3/cr4 - put "lock works" in the PAT and while we'll > have to add PAT support which we need to do anyway we would get a world > where on uniprocessor lock prefix only works on addresse targets we want > it to - ie pci_alloc_consistent() pages.
Given the CPU architecture it is unimplementable. Intructions are split into microinstuctions and they are executed out of order. PAT is looked up when LOAD microinstruction is executed. Imagine this
MOV EDX, [address1] LOCK ADD [address2], EDX
that is translated to
LOAD EDX, [address1] LOAD TMP1, [address2] ADD TMP1, EDX STORE [address2], TMP1
... now LOAD finds LOCK attribute in PAT --- so it locks the bus, however EDX is still not loaded. Now LOAD EDX can't execute because the bus is locked and ADD and STORE can't execute because they're waiting for LOAD EDX. Deadlock.
Locks are so slow not because they are locks (if the target is in L1 cache, they operate only on cache and don't go to bus at all), but because they need to flush completely microinstruction pool to avoid problems like this. Of course Intel won't waste silicon in the execution engine for instructions that execute so rarely, so they microcode them instead. So lock detection is done at the decoder.
Mikulas
> Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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 More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |