lkml.org 
[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: kmalloc optimization
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.037 / U:2.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site