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. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "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
