Messages in this thread | | | From | "Michael S. Zick" <> | Subject | Re: LOCK prefix on uni processor has its use | Date | Wed, 27 May 2009 13:22:39 -0500 |
| |
On Wed May 27 2009, Andi Kleen wrote: > Harald Welte <HaraldWelte@viatech.com> writes: > > * All X86 instructions except rep-strings are atomic wrt interrupts. > > * The lock prefix has uses on a UP processor: It keeps DMA devices from > > interfering with a read-modify-write sequence > > In theory yes, but not in Linux -- normal drivers simply don't use LOCK in any way > on a UP kernel. > > We discussed exactly this in the earlier subthread :) > > > Now the question is: Is this a valid operation of a driver? Should the driver > > do such things, or is such a driver broken? > > The driver is broken because if it relies on this it will not work on a UP kernel. > Also it's not portable and in general a bad idea. > > > When would that occur? I'm trying > > to come up with a case, but typically you e.g. allocate some DMA buffer and > > then don't touch it until the hardware has processed it. > > Is it known which driver has this problem? > > -Andi (who finds hpa's "timing theory" to be more believable anyways) >
I still have not come up with a solid, testable, theory to explain the order of magnitude in up-time before the kernel locks with/with-out 'lock'.
But we are definitely pecking around the edges of the problem. ;)
Today's lockdep build has just passed its previous record by hard-coding the pci cache line size to be the same as the cpu's cache line size. (a WAFG). Until we hear back from the VIA-CPU people, I just guessed that since the chip set was designed for use with the processor...
Mike
| |