From dev-return-3105-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sun Jul 08 17:45:03 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 83959 invoked by uid 500); 8 Jul 2001 17:45:03 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 83948 invoked from network); 8 Jul 2001 17:45:03 -0000 Date: Sun, 8 Jul 2001 10:45:06 -0700 (PDT) From: dean gaudet To: Ben Laurie cc: Subject: Re: Observations on fragmentation in SMS pools In-Reply-To: <3B4826E4.A46B687A@algroup.co.uk> Message-ID: X-comment: visit http://arctic.org/~dean/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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. -dean