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. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev