Re: Linux 2.6.30-rc8 [also: VIA Support]

[Robert Hancock <hancockrwd@gmail.com>]

Michael S. Zick wrote:
> On Thu June 4 2009, Andi Kleen wrote:
>> Harald Welte <HaraldWelte@viatech.com> writes:
>>> why would it matter on UP? as indicated, I'm not the expert here, but I thought
>>> memory ordering issues only arise in SMP systems [or possibly with regard to
>>> DMA, but as we already explored much earlier in this thread, drivers that access
>>> DMA buffers whil the hardware owns them are buggy and need to be fixed]
>> Sorry we didn't establish that. Accessing data structures that are
>> also accessed by DMA hardware is pretty common in fact and memory
>> ordering issues also come up regularly (e.g. all the infamous PCI
>> posting bugs)
>>
>> What we established is that the drivers don't use LOCK for it
>> (or at least we think that's very unlikely)
>>
> 
> It was a real headache in the pa-risc port - -
> Even went so far as to build some experimental kernels where all
> the spin-lock structures where in a separate loader section.
> 
> That was to avoid in-direct interference - I.E: Both DMA and
> the processor handling the locking **both** invalidating the
> same cache line at the same time (only one can win).
> 
> Things might get that deep with this processor/chip-set combination;
> but pa-risc has some very unusual hardware in some older models.

That sort of thing should be architecturally impossible on x86. In order 
for something to invalidate the cache line, it first has to own it 
(except maybe for some unusual cases like Memory Write and Invalidate 
where the writer promises to overwrite the entire cache line).