Power-of-two sized chunks aligned on the size's boundary are suboptimal.
The alignment matters here, not the size. This problem is solved with
the slab coloring, even with power-of-two object sizes.
Of course, closely spaced list of default sizes wouldn't hurt, it'll
probably reduce the internal fragmentation a bit (but don't hold you
breath).
Anyway, I wish to propose another improvement(?).
Since the underlying page allocator is a binary buddy one
it is possible to get the address of the slab control
by mere address calculation. Thus, there ain't no need for
any hash tables, bufctls, indices, etc., i.e. there is no
difference between "large" and "small" object caches.
Another improvement(?) resulting from the above one is
that there is no need for artificial (no matter if empirically
justified) object size threshold, so the allocator can choose
better slab sizes.
If anyone is interested I can send him such a slab allocator
implementation (user mode, written for the sole prupose of
playing with it, i.e., not particularly optimized,
some stuff missing, e.g., slab shrinking, etc.)
Regards,
-velco
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/