ad7877: keep dma rx buffers in seperate cache lines
in [Kernel]
|
From: Mike Frysinger on 11 May 2010 13:40 On Tue, May 11, 2010 at 12:52, Dmitry Torokhov wrote: > On Tue, May 11, 2010 at 09:42:03AM +0300, Pekka Enberg wrote: >> On Tue, May 11, 2010 at 9:33 AM, Dmitry Torokhov wrote: >> >> what guarantee exactly do you have for that statement ? >> > >> > The data is kmalloced, kmalloc aligns on cacheline boundary AFAIK which >> > means that next kmalloc data chunk will not share "our" cacheline. >> >> No, there are no such guarantees. kmalloc() aligns on >> ARCH_KMALLOC_MINALIGN or ARCH_SLAB_MINALIGN depending on which is >> bigger but beyond that, there are no guarantees. You can, of course, >> use kmem_cache_create() with SLAB_HWCACHE_ALIGN to align on cacheline >> boundary. > > The architectures that we are trying to deal with here should be forcing > kmalloc to the cache boundary already though - otherwise they would not > be able to used kmalloced memory for DMA buffers at all. Or am I utterly > lost here? i dont want to restrict the driver so that it implicitly only works on certain arches. that kind of goes against the entire point of the driver model. the only thing this driver needs is a SPI bus, and people can easily do that on most every arch. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 11 May 2010 15:10 Dmitry Torokhov wrote: > The architectures that we are trying to deal with here should be forcing > kmalloc to the cache boundary already though - otherwise they would not > be able to used kmalloced memory for DMA buffers at all. Or am I utterly > lost here? I don't know which architecture you're talking about but it's not true in general and you probably don't want to depend on it even if it happens to work now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matt Mackall on 11 May 2010 16:10 On Tue, 2010-05-11 at 16:03 -0400, Mike Frysinger wrote: > On Tue, May 11, 2010 at 02:42, Pekka Enberg wrote: > > On Tue, May 11, 2010 at 9:33 AM, Dmitry Torokhov wrote: > >>> what guarantee exactly do you have for that statement ? > >> > >> The data is kmalloced, kmalloc aligns on cacheline boundary AFAIK which > >> means that next kmalloc data chunk will not share "our" cacheline. > > > > No, there are no such guarantees. kmalloc() aligns on > > ARCH_KMALLOC_MINALIGN or ARCH_SLAB_MINALIGN depending on which is > > bigger but beyond that, there are no guarantees. You can, of course, > > use kmem_cache_create() with SLAB_HWCACHE_ALIGN to align on cacheline > > boundary. > > so how is this to be addressed in general ? this is a problem for any > device that does SPI transactions, and having every driver create its > own kmem cache isnt the answer. > > do people need to kmalloc() like 2x the desired size and manually > align it themselves ? declaring alignments on struct members doesnt > matter if the base of the struct isnt aligned. seems like we need a > new GFP flag that says we need a cache aligned pointer so we can give > that to kmalloc() and such. Make your own slab cache with the alignment flag set, as Pekka already mentioned. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Frysinger on 11 May 2010 16:10 On Tue, May 11, 2010 at 02:42, Pekka Enberg wrote: > On Tue, May 11, 2010 at 9:33 AM, Dmitry Torokhov wrote: >>> what guarantee exactly do you have for that statement ? >> >> The data is kmalloced, kmalloc aligns on cacheline boundary AFAIK which >> means that next kmalloc data chunk will not share "our" cacheline. > > No, there are no such guarantees. kmalloc() aligns on > ARCH_KMALLOC_MINALIGN or ARCH_SLAB_MINALIGN depending on which is > bigger but beyond that, there are no guarantees. You can, of course, > use kmem_cache_create() with SLAB_HWCACHE_ALIGN to align on cacheline > boundary. so how is this to be addressed in general ? this is a problem for any device that does SPI transactions, and having every driver create its own kmem cache isnt the answer. do people need to kmalloc() like 2x the desired size and manually align it themselves ? declaring alignments on struct members doesnt matter if the base of the struct isnt aligned. seems like we need a new GFP flag that says we need a cache aligned pointer so we can give that to kmalloc() and such. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Frysinger on 11 May 2010 16:20
On Tue, May 11, 2010 at 16:07, Matt Mackall wrote: > On Tue, 2010-05-11 at 16:03 -0400, Mike Frysinger wrote: >> On Tue, May 11, 2010 at 02:42, Pekka Enberg wrote: >> > On Tue, May 11, 2010 at 9:33 AM, Dmitry Torokhov wrote: >> >>> what guarantee exactly do you have for that statement ? >> >> >> >> The data is kmalloced, kmalloc aligns on cacheline boundary AFAIK which >> >> means that next kmalloc data chunk will not share "our" cacheline. >> > >> > No, there are no such guarantees. kmalloc() aligns on >> > ARCH_KMALLOC_MINALIGN or ARCH_SLAB_MINALIGN depending on which is >> > bigger but beyond that, there are no guarantees. You can, of course, >> > use kmem_cache_create() with SLAB_HWCACHE_ALIGN to align on cacheline >> > boundary. >> >> so how is this to be addressed in general ? this is a problem for any >> device that does SPI transactions, and having every driver create its >> own kmem cache isnt the answer. >> >> do people need to kmalloc() like 2x the desired size and manually >> align it themselves ? declaring alignments on struct members doesnt >> matter if the base of the struct isnt aligned. seems like we need a >> new GFP flag that says we need a cache aligned pointer so we can give >> that to kmalloc() and such. > > Make your own slab cache with the alignment flag set, as Pekka already > mentioned. and like i said, that doesnt sound like a reasonable solution when every single SPI driver (over 100 atm) out there is affected -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |