Messages in this thread |  | | Subject | Re: kmalloc optimization | From | David Wragg <> | Date | 27 Aug 2000 13:10:30 +0000 |
| |
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/
|  |