You're assuming that the slab allocator always returns cachesize-padded
objects. It does not have to do that. It can return 4-byte-sized and
-aligned objects if you ask it to.
> Does this make a reasonable case for interlaced allocator now?
> (Of course, blklist init in the patch has to be modified to create
> blklists for objects of size 4, 8 .... SMP_CACHE_BYTES/2)
Oh I can see the benefits, but they appear to be rather theoretical.
I'm just applying some pressure here against adding another allocator
unless it is really needed. On principle.
A slab cache of 4-byte objects will tend to give you what you want
anyway, due to the batch filling and freeing of the head arrays.
If that is proven to be insufficient then it would be better to
put development effort into strengthening slab, rather than competely
(And a really simple solution would be to create a separate slab cache
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/