>>Replying to myself.... Anyway, I realized that even my idea above is >>wrong. I don't see _any_ safe way to share a cache line between a DMA >>buffer and other data. Access to the cache line might pull the cache >>line back in and write it back at any time, which could corrupt the >>DMA'ed data. I don't see a way to hide the existence of cache lines >>etc. from the driver.
Right, I'd expect this kind of solution to fix the problem: > A simpler alternate fix might have been to declare that field as aligned, > which I think goes more or less like > > char buffer [...] __attribute__ (aligned (L1_CACHE_BYTES)); > > and size it accordingly, maybe after rearranging fields. (Using SMP_CACHE_BYTES I guess, though it's not clear to me that synchronizing with other CPUs would have the same requirement as synchronizing to various devices.) Might be good to stick such data at the end of structures, since when they're kmalloced in cacheline-aligned chunks, aligning the start of such buffers is sufficient to prevent any cacheline sharing. I'm not at all surprised to find that on systems where the hardware does less (for e.g. cache coherency), the software talking to other hardware (devices, CPUs) needs to shoulder a bit more work. The good news is that once it's done right, it's like aligning data types to their "natural" sizes: all systems get faster, since the hardware doesn't have to slow down and fix up problematic accesses. After all, that's exactly why higher end systems avoid having that kind of hardware fixup in the first place! - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
