Not coherent cache DMA for G3/G4 CPUs: clarification needed
Benjamin Herrenschmidt
benh at kernel.crashing.org
Fri Apr 21 08:39:29 EST 2006
On Thu, 2006-04-20 at 14:13 -0700, Eugene Surovegin wrote:
> On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > Unfortunately, he has to do things a bit differently. He can't afford to
> > have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
> > a reserved pool. Last I looked at our coherent code, it didn't reserve
> > memory at all, just address space, thus assuming the CPU can handle
> > having both a caheable and a non-cacheable mapping of the same pages...
> > (On 6xx this is deadly even if you don't access those cacheable pages
> > because the CPU prefetch may do it for you).
>
> Ben, is this _real_ problem on 6xx or just a theory? Does 6xx actually
> prefetch beyond page boundary?
>
> So far, all "prefetching" I saw which broke non-coherent DMA was not
> due to the CPU doing prefetching, but _software_ prefetching being
> too aggressive.
Not 100% certain... we definitely have a bug with AGP on macs currently
for that reason though I yet have to isolate a crash caused by it ;)
(That is, we map AGP pages non-cacheable but they stay in the linear
mapping).
On POWER4, 970 and later, the chip guys confirmed that the problem is
real though. Not only bcs of prefetch but also speculative execution
which can cause the chip to do a load that will never actually be
executed. Imagine for example a loop walking an array, the chip might
speculatively load elements beyond the array by speculatively executing
beyond the branch that ends the loop.
Ben.
More information about the Linuxppc-dev
mailing list