On Sun, Mar 13, 2005 at 06:00:01PM -0500, Jon Smirl wrote: > On Mon, 14 Mar 2005 09:20:01 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> 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ä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
