lkml.org 
[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kmalloc optimization
On Sun, Aug 27, 2000 at 05:08:37PM +0100, Mark Hemment wrote:
> It is possible to add the necessary data capture abilities to
> kmalloc() and friends, with a build time option. This would allow users
> to gather the stats for their own work loads.

surprise ;)

>
> My latest version of the Slab allocator (still haven't got round to
> finishing the thing off), allows new sizes to be added dynamically without
> needing to have a lock guarding the linkages between the different general
> cache size nodes (gnodes).

I implemented it in the past and tried it for networking (tuning slab sizes
to MTUs, some remnants are still skbuff.c). I just used a stop the world
scheme, so no locking was needed. It unfortunately performed badly because
of the large page orders needed so I dropped it.

> The standard (power-of-2) general caches' gnodes are from contigious
> memory, so they can be indexed into after a find-highes-set-bit operation.

It is just not done, and I think it is not worth it.

> Also, slabs can be shared between caches where the objects are of
> similar size. This allows a specific cache to also be exported as a
> general cache (still giving correct object usage counts for each sharing
> cache). The only disadvantage there is increased lock contention inside
> my slab_info structures, but heavily used caches can insure they don't
> share via a SLAB_PERFORMANCE creation flag.

Wouldn't that destroy one of the most important advantages of a zone allocator?
(clustering objects with similar livetime to avoid fragmentation)

> > 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)
>
> Many of the remaining, general size, allocations are not performance
> critical. Of the ones which are, networking (the data buffers for
> skbufs) are by far the most important one to tackle.

I'm worrying less about performance than about memory usage and fragmentation
(slab pages tied although they only have a few active objects left)

>
> > 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)
>
> Doesn't matter (too much).

On 32MB machines it was a big problem in my experiments.


-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/

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