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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
