radeon, apertures & memory mapping

[Ville Syrjälä]

On Sun, Mar 13, 2005 at 06:00:01PM -0500, Jon Smirl wrote:
> On Mon, 14 Mar 2005 09:20:01 +1100, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
> > Though the flushes may be fast if there is no actual hit in the cache, I
> > agree. Again, that should be benched.
> > 
> > In fact, i would _love_ to be able to mark AGP memory as cacheable on
> > ppc, even if there is no performance benefit in the end. The issue is
> > that currently, we end up having both a cacheable and a non-cacheable
> > mapping for those pages (the kernel linear mapping still maps those
> > pages cacheable, and it's almost impossible to get rid of that unless
> > you are prepared to disable the large pages mapping of kernel space or
> > the BATs on ppc32, which would harm kernel performances significantly).
> > 
> > It works, but it's illegal. That means that the CPU might well speculate
> > a load from one of these pages in kernel-land just because it happens to
> > be next to a page where you are iterating an array, and may then bring a
> > bit in the cache from that page.
> 
> That shouldn't matter the page brought in would be for a speculative
> read and never accessed. It should just fall out of the cache and not
> be written back. There is only one cachable mapping. In this model
> writes are always followed by a flush before telling the GPU to access
> the memory that has just been written.

What about this scenario?

Speculative read -> AGP master writes new data -> CPU has invalid data in 
cache :(

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/