Messages in this thread | | | From | "Michael S. Zick" <> | Subject | Re: Linux 2.6.30-rc8 [also: VIA Support] | Date | Thu, 4 Jun 2009 19:52:34 -0500 |
| |
On Thu June 4 2009, Robert Hancock wrote: > 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). > >
VIA has not publicly published sufficient technical information to presume that the cache coherency control protocols are the same as Intel's.
These are cpu/chipset pairs - Think System On 2 Chips. SoS2C.
Mike Mike
| |