Momchil Velikov <velco@fadata.bg> writes:
> 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).
No, it seems kernel objects commonly don't fit very well into power of
two blocks.
It has nothing to do with the usual power-of-two cache underuse problem.
>
> 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.
Nice idea. That could clean a lot of cruft. It may get slightly
more complicated again with multiple zones though.
-Andi
-
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:22 EST