From owner-freebsd-current Fri Feb 1 14:16:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by hub.freebsd.org (Postfix) with ESMTP id 2F17D37B405 for ; Fri, 1 Feb 2002 14:16:37 -0800 (PST) Received: from [192.168.1.129] (212.129.46.20) by mail.libertysurf.net (5.1.053) id 3C5A03D80002F149; Fri, 1 Feb 2002 23:15:45 +0100 Date: Fri, 1 Feb 2002 00:15:55 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-X-Sender: To: Erik Trulsson Cc: Jason Evans , Kenneth Culver , "Cameron, Frank" , Terry Lambert , David Malone , "'freebsd-current@freebsd.org'" Subject: Re: AMD AGP Bug In-Reply-To: <20020201215006.GA50090@student.uu.se> Message-ID: <20020131235643.J2210-100000@gerard> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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