Andi Kleen <ak@suse.de> writes:
> The power of two buckets have to go sooner or later anyways, because they're
> fairly suboptimal. They're really only a leftover from the old kmalloc.
> So therefore I don't think it makes too much sense
> to apply your patch now, because it would have to be removed again later.
What do you have in mind? Still using slabs for kmalloc, but adding
non-power-of-two-sizes? Adding buckets of size (2^n)*1.5 would be
straightforward, and should get most of the benefit, if there is
benefit to be had.
> BTW, there would be a much better more cycle saving optimization: for the
> common case of a constant argument to kmalloc you can check for it
> using __builtin_constant_p and select the right slab at compile time.
> (this should be usually faster than your ffz hack and can be easily adapted
> to other default slab sizes too)
Yes, this would be help the cases which use kmalloc because they don't
allocate enough objects to make use of a slab cache worthwhile (other
remaining cases of kmalloc with constant size should be converted to
use their own slab caches, no?). But since those cases are not doing
a lot of allocations, the overall benefit might not be that great.
My "hack" should help with things like the kmalloc done by alloc_skb
(though a slab cache of 1500 byte buffers might be even better for the
high performance network drivers; (2^n)*1.5 byte buckets should also
work well for this case).
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST