On 05/04/11 16:55, Alexander Stein wrote: > Hello, > > Am Mittwoch, 4. Mai 2011, 17:49:56 schrieb Jonathan Cameron: >> On 05/04/11 16:22, Alexander Stein wrote: >>> req.sample needs its own cacheline otherwise accessing req.msg fetches >>> it in again. >>> Put req onto stack as it doesn't need to be DMA save. >>> req.sample is kzalloced itself for DMA access. >>> req.command doesn't need own cache line because it will only be written >>> to memory on dma_map_single. req.scratch is unsed at all. >>> >>> Note: This effect doesn't occur if the underlying SPI driver doesn't use >>> DMA at all. >> >> How about using ____cacheline_aligned having moved 'sample' to the end of >> the structure? >> >> e.g. >> >> ... >> struct spi_transfer xfer[6]; >> __be16 sample ____cacheline_aligned; >> } >> >> Rather smaller patch when you get down to it. > > Mh, I didn't know I had to reorder the struct elements to use > ____cacheline_aligned. I originally had a solution in mind with a smaller > memory footprint in mind, but rethinking about it, this might be negligible if > there is one at all. > So, if ____cacheline_aligned is the more sane approach I'll resend a patch > using it. It simply enforces that element being aligned. Thus if there is anything after it you may well have things in the same cacheline. Obviously you could use align the following element to ensure its on the next cache line, but thats silly when you can just reorder to make sure nothing is there. All mallocs are guaranteed to get a whole number of cachelines. (would be really fiddly otherwise!) Footprint wise, it should be pretty trivial. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
