slab debug vs. L1 alignement
Currently, when enabling slab debugging, we lose the property of having the objects aligned on a cache line size.
This is, imho, an error, especially if GFP_DMA is passed. Such an object _must_ be cache alined (and it's size rounded to a multiple of the cache line size).
There is a simple performance reason on cache coherent archs, but there's also the fact that it will just _not_ work properly on non cache-coherent archs. Actually, I also have to deal with some old machines who have a SCSI controller who has a problem accessing buffers that aren't aligned on a cache line size boundary.
This is typically causing me trouble in various parts of SCSI which abuses kmalloc(512, GFP_KERNEL | GFP_DMA) for buffers passed to some SCSI commands, typically "utility" commands used to read a disk capacity, read read/write protect flags, some sense buffers, etc...
While I know SCSI shall use the consistent alloc things, it has not been fully fixed yet and kmalloc with GFP_DMA is still valid despite not beeing efficient, so we should make sure in this case, the returned buffer is really suitable for DMA, that is cache aligned.
Ben.
Quoted 18 lines · Benjamin Herrenschmidt
Currently, when enabling slab debugging, we lose the property of having the objects aligned on a cache line size.
This is, imho, an error, especially if
GFP_DMAis passed. Such an object _must_ be cache alined (and it's size rounded to a multiple of the cache line size).There is a simple performance reason on cache coherent archs, but there's also the fact that it will just _not_ work properly on non cache-coherent archs. Actually, I also have to deal with some old machines who have a SCSI controller who has a problem accessing buffers that aren't aligned on a cache line size boundary.
This is typically causing me trouble in various parts of SCSI which abuses
kmalloc(512, GFP_KERNEL | GFP_DMA)for buffers passed to some SCSI commands, typically "utility" commands used to read a disk capacity, read read/write protect flags, some sense buffers, etc...
Quoted 4 lines
While I know SCSI shall use the consistent alloc things, it has not been fully fixed yet and kmalloc with
GFP_DMAis still valid despite not beeing efficient, so we should make sure in this case, the returned buffer is really suitable for DMA, that is cache aligned.
Attached untested patch should fix it (vs 2.6.0-test1), I've no idea if it's acceptable.
regards
Philippe Elie
slab.c renamed from slab.c~ +1 -1
@@ -682,7 +682,7 @@ sizes->cs_dmacachep =kmem_cache_create ( names->name_dma, sizes->cs_size, -0 ,SLAB_CACHE_DMA |SLAB_HWCACHE_ALIGN ,NULL ,NULL ); +0 ,SLAB_CACHE_DMA |SLAB_MUST_HWCACHE_ALIGN ,NULL ,NULL );if (!sizes->cs_dmacachep)BUG ();
Quoted 3 lines
Attached untested patch should fix it (vs 2.6.0-test1), I've no idea if it's acceptable.
That will just disable redzoning, which isn't what I want...
Quoted 7 lines · Benjamin Herrenschmidt
Currently, when enabling slab debugging, we lose the property of having the objects aligned on a cache line size.
This is, imho, an error, especially if
GFP_DMAis passed. Such an object _must_ be cache alined (and it's size rounded to a multiple of the cache line size).
Well the theory is that SLAB_HWCACHE_ALIGN is advisory and SLAB_MUST_HWCACHE_ALIGN is compulsory.
You're looking for compulsory alignment on the generic kmalloc() slab pools, so we're a bit screwed.
I guess the redzoning would need to be taught to always pad by a full cacheline.