On Sun, Aug 27, 2000 at 01:10:30PM +0000, David Wragg wrote:
> 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.
The best numbers have to be determined, it requires extensive profiling runs.
Also the most heavy users are probably better converted to direct calls
of kmem_cache_alloc (looking at my /proc/slabinfo there must be some heavy
user who doesn't do that for a size <=32bytes)
>
> > 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).
1500bytes slab unfortunately is not too useful, because it does not fit well
in 4K pages (you would need 8K or 16K page allocations, which the mm system
does not like much due to fragmentation)
I guess the best optimization for alloc_skb would be a binary search.
-Andi
-
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