Andi Kleen wrote:
> Here are some additional ideas of slab improvement that I wanted to implement
> for ages, but never got around:
>
> - Use a better set of default sizes for the constant sized slabs. Bonwick
> mentions in the original paper that power of two slabs are close to s
> uboptimal. Best would be to have a simple profiler where everybody could
> generate the optimal set for the particular workload.
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/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:20 EST