[PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat Jan 12 12:52:55 EST 2008

On Fri, 2008-01-11 at 14:38 -0800, Eugene Surovegin wrote:
> On Sat, Jan 12, 2008 at 09:05:35AM +1100, Benjamin Herrenschmidt wrote:
> > 
> > > >  The s/w synchronization algorithms proposed in my patches has no LL PLB 
> > > > limitations as opposed to h/w snooping, but, probably, this is not the best 
> > > > way of how it might be implemented. Even though with these patches the h/w 
> > > > accelerated RAID starts to operate correctly (with L2-cache enabled) there is 
> > > > a performance degradation (induced by loops in the L2-cache synchronization 
> > > > routines) observed in the most cases. So, as a result, there is no benefit 
> > > > from using L2-cache for these, RAID, cases at all.
> > > 
> > > Thanks a lot for explanation, Yuri. I'd never imagine they were so 
> > > stupid to make new chips with such behaviour.
> > 
> > Indeed. Now the question is do we want to make that configurable by the
> > platform so it can select whether to enable snooping, or use this
> > mechanism (in which case we can disable snooping on the L2) ?
> I don't think we should panish platforms with sane L2 caches, because 
> there are some brain-dead ones.

I agree, which is why I'm thinking about making it some kind of explicit
thing that a give platform would call from it's setup_arch() callbacks
to turn on manual L2 sycnhronization.

> > Another option would be to make the dma_ops smart enough to know whether
> > a given device is on the snooped portion of the bus, which would be
> > easier to do after I merge 32 and 64 bits DMA ops, so we get the ability
> > to change the dma-ops per bus or per device even.
> > 
> > What do you guys think ?
> I like the idea of having smart DMA routines with different 
> per-bus/device behaviour.

That would be longer term. When I merge the dma ops, I'll look into a
way to provide 44x specific DMA ops that handle that case, and then a
way for devices to be tagged (maybe via the device-tree) on whether they
are on an L2 coherent or non-L2 coherent segment of the bus.


More information about the Linuxppc-dev mailing list