Erik Trulsson wrote: > > The Athlon rewriting same value to cacheable memory under the knees of > > programmers looks a severe issue to me if it is true. Not only AGP memory > > can be affected. What about SMP, MMIO (if some cacheable mapping exists), > > etc...? > > I am not familiar with the acronym MMIO is so I can't comment on that.
"Memory Mapped I/O". 8-). > In general though, having memoryspace used for memory-mapped I/O > devices (including AGP) marked as cacheable is a bad idea unless you > are very careful and know exactly what you are doing. "What he said". 8-) 8-). > For SMP it shouldn't be any problem. Multi-CPU systems normally > run some cache-coherence protocol between themselves to make sure that > things like this is not a problem. I think the problem is pages in which there are inter-CPU locks being set and cleared. Say you had a speculative write that would clear a lock, only you decide not to clear it because it doesn't happen. > > In my opinion, OSes having some cacheable mapping to AGP memory is not the > > real problem. Just it has revealed the AMD issue. > > It might be argued that there should be some cache-coherence protocol > between the CPU and the AGP device. This is what Bruce and Peter suggested; Peter said that he was working on a rewrite of the pmap code and would look in that area. > Not knowing how AGP is specified I don't know if this interaction > between the CPU and AGP is a bug or just working as specified. I > suspect it is the latter though. "If it doesn't have to be correct, I can make it as fast as you want!" "The CPU is so fast, it can execute an infinite loop is 6 seconds!" -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message