From: Paul Mundt <lethal@xxxxxxxxxxxx> Date: Wed, 19 May 2010 07:35:10 +0900 > On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller wrote: >> So one of two things should happen: >> >> 1) SLOB conforms to SLAB/SLUB in it's test >> >> 2) SLAB/SLUB conforms to SLOB in it's test >> >> And yes this is an either-or, you can't say they are both valid. > > I don't see any reason to punish SLOB for the assumptions that SLAB/SLUB > arbitrarily took up, presumably on an architecture that should have > specified its own alignment requirements and simply couldn't be bothered. > Making SLAB redzoning work with arbitrary alignment is another matter > entirely, and something that should probably be revisited. > > Anything that assumes more than BYTES_PER_WORD is simply broken and > should be reverted. You can't make the default different in each allocator, PERIOD. If you can't know what the default is, how in the world can you know if you need to override it? You can't. It's a guess, and you can't say otherwise. All of the CPP tests like the one used by linux/crypto.h are ludicrious. It should absolutely be not necessary for any code to duplicate this kind of calculation. Instead, this sequence should be in linux/slab.h, and be used universally by slab, slub, slob and anything that wants to know the allocators alignment guarentees. I don't even know of a 32-bit chip outside of x86 that doesn't potentially emit alignment requiring 64-bit memory operations for 64-bit objects. So what SLOB is doing with a different default is even more strange. And I bet you that even without the requirement, x86 runs faster with 64-bit alignment of 64-bit objects. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
