On Sat, Feb 04, 2006 at 12:51:07AM -0700, Stephen Deasey wrote: > There's some memory related links in this blog post I read recently: > > http://primates.ximian.com/~federico/news-2005-12.html#14 > > Federico makes a good point: this has all been done before...
Hm, he links to these two: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html The 1994 "Slab Allocator" was used in SunOS 5.4 (Solaris 2.4). The 2001 "Vmem" and "libumem" version uses a "per-processor caching scheme ... that provides linear scaling to any number of CPUs." (Nice paper!) That seems reasonable. I figure that the CPU is what does the work, so per-thread memory caching as done the Tcl/AOLserver "zippy" allocator is only necessary because threads are not tied to any one CPU. If they were, it would be better to have those N threads all use the same memory cache for their allocations, as obviously only 1 can allocate at any given time. Interestingly, libumem, the non-kernel version of their work, they (initially?) usedper-thread rather than per-cpu caches, because the Solaris thread library didn't have the right APIs to do things per CPU. Apparently that worked fine, and it was still faster than Hoard (by a constant amount, they both scaled linearly). However, their tests only seem to use only 1 thread per CPU though, which isn't terribly realistic. Allocator CPU-affinity is probably much more useful when you have 100 or 1000 threads per CPU, and it might be interesting to see scalability graphs under those conditions. Some of the benchmarks are impressive, on large multi-cpu boxes they cite 2x throughput improvement on a Spec web serving benchmark by adding their new stuff to Solaris. And it even improves single cpu performance somewhat too. The paper clearly says that the userspace version beats Hoard, ptmalloc (Gnu libc), and mtmalloc (Solaris), which it calls "the strongest competition". As of 2001 glibc's allocator was clearly crap for anything other than single-thread code - thus the traditional need for hacks like the zippy allocator. One interesting bit is that: "We discussed the magazine layer in the context of the slab allocator, but in fact the algorithms are completely general. A magazine layer can be added to ANY memory allocator to make it scale." The work described in that 2001 paper has all been in Solaris since version 8. Do Linux, FreeBSD, and/or Gnu Libc have this yet? Ah, Mena-Quintero's blog above says that "gslice" is exactly that, and seems to be in Gnome 2.10: http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slices.html Shouldn't something like that be in ** Gnu LibC **, not just in Gnome? Bonwick's brief concluding thoughts about how OS core services are often the most neglected are also interesting. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
