Skip to contentSkip to conversation

slab debug vs. L1 alignement

BUG Benjamin Herrenschmidt 3 participants 4 messages Aug 15, 2003

lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw
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_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...

Quoted 4 lines

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.

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();
 
#2 lore raw
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...

#3 lore raw
In reply to Benjamin Herrenschmidt
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_DMA is 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.