Date: Fri, 1 Feb 2002 00:15:55 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> To: Erik Trulsson <ertr1013@student.uu.se> Cc: Jason Evans <jasone@canonware.com>, Kenneth Culver <culverk@yumyumyum.org>, "Cameron, Frank" <Cameron@ctc.com>, Terry Lambert <tlambert2@mindspring.com>, David Malone <dwmalone@maths.tcd.ie>, "'freebsd-current@freebsd.org'" <freebsd-current@FreeBSD.ORG> Subject: Re: AMD AGP Bug Message-ID: <20020131235643.J2210-100000@gerard> In-Reply-To: <20020201215006.GA50090@student.uu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Feb 2002, Erik Trulsson wrote: > On Thu, Jan 31, 2002 at 09:32:48PM +0100, G=E9rard Roudier wrote: > > > > > > On Thu, 31 Jan 2002, Jason Evans wrote: > > > > > On Wed, Jan 30, 2002 at 11:14:48PM +0100, G=E9rard Roudier wrote: > > > > > > > > Linux can be fixed, but the useless writes of the existing Athlons = from > > > > the very fast cache to the relatively very slow memory cannot. And = all > > > > Athlon users may well pay this penalty under any OS... unless we w= ant to > > > > disable caching. :) > > > > > > Have you done benchmarks to show that the speculative writes are usel= ess > > > often enough to cause enough memory bus contention that overall perfo= rmance > > > is degraded, despite the speedups when the speculative writes are val= id? > > > > I haven't done any benchmark of this sort, neither intend to do any sin= ce > > I haven't time for that. But I wrote in my email that my 2 Athlon syste= ms > > worked fine and fast, just to indicate that for normal use I didn't see > > any performance problem at all. > > > > > I > > > suspect that AMD in fact performed such tests; otherwise they wouldn'= t have > > > gone to the trouble of implementing speculative writes. > > > > 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 memo= ry > > 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. > > 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. Normally you just need a non-cachable mapping. Nothing should preclude to also have cachable mappings as long as programs donnot misuse _explicitely_ any of the existing mappings. > 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. Theory looks perfect, reality is different. Just I am under the impression that Intel speak about their hardware errata a lot more clearly than AMD seem to do. > > 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. 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. AGP does not require cache to snoop AGP accesses to memory, but it perfectly allows implementations to ensure such coherency. As a result, AGP softwares must not rely on that. I guess that neither Windows 2000 nor Linux were/are relying on such coherency that is explicetely not required by AGP specifications. I never read that AGP specifications allow CPU to screw up AGP memory in the back of actually executed program instructions. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020131235643.J2210-100000>