> > > I don't follow you. What's inefficient about this? It looks like the
> > > decision of whether or not to call dma_cache_wback_inv() has nothing to
> > > do with what other data is stored in the same memory block with the
> > > output buffer. And there's nothing that indicates
> > > dma_cache_wback_inv() is less efficient when ptr isn't aligned on a
> > > cacheline.
> >
> > No, I meant sharing it. You'd get a full hard cache miss.
>
> I get it. The writeback-and-invalidate means that the next time the CPU
> tries to access any data in that region of memory it must wait for the
> cache to fill up. And apparently the MIPS doesn't support writeback
> without invalidating, which would make more sense for DMA_OUT operations.
Why? If you write it out, you should be done with it. As cache is a limited
resource, you should free what you can.
> So your point that output buffers shouldn't share memory regions is well
> taken.
>
> On the other hand, for DMA_IN it is most likely that the next piece of
> data the CPU will access in that memory region is the input buffer itself.
> Especially if the memory region is devoted only to input buffers and the
> input operations occur sequentially. So nothing is lost by incurring a
> cache miss there, because the CPU would have to refill its cache anyway.
In this case it's an issue of correctness. Prefetching the data is sensible
with physical caches. On a virtually indexing CPU prefetching seems
sensible only if you need the data in kernel space.
This makes me wonder how noncoherent architectures implement /dev/kmem
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
