apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: Observations on fragmentation in SMS pools
Date Sun, 08 Jul 2001 19:14:40 GMT
dean gaudet wrote:
> On Sun, 8 Jul 2001, Ben Laurie wrote:
> > Justin Erenkrantz wrote:
> > > Aaron pointed out that CLR (Cormen/Leiserson/Rivest for those that never
> > > took algorithms classes) has many memory allocation algorithms.  I'd
> > > bet we could find one that would work better.  -- justin
> >
> > At USENIX there was a talk about extending the slab allocator to
> > multiple CPUs. One of the things in the talk was a thing called vmem,
> > which is a general purpose resource allocator with low fragmentation and
> > constant-time allocations (optionally - for more time you can get a
> > better fit). Sounds pretty good, eh?
> >
> > http://www.usenix.org/publications/library/proceedings/usenix01/bonwick.html
> linux 2.4 uses a slab allocator for many critical data structures -- in
> particular the networking code uses it.  this is one of the tricks they
> used betwen 2.2 and 2.4 to increase the scalability to large numbers of
> CPUs.  their allocator does have per-cpu caching, but i don't remember all
> the details.

I should be clear: this gadged goes underneath the slab allocator. That
is, the slab allocator uses memory allocated by vmem. Apparently, this
is because slab allocators always defer the question of how to get big
lumps of memory, and vmem is what it is proposed it should defer it to.

BTW, the obvious thing to do to cure the problem described in the first
place is to not add extra memory after the first step up the tree.




"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

View raw message