On Thu, Oct 22, 2009 at 7:18 PM, Nitin Gupta <[email protected]> wrote: > I have never gone though jemalloc details but if it satisfies above > requirements > and also gives low fragmentation under these constraints then it can surely be > used for compcache.
AFAICT, Out-of-the-box jemalloc would be useless. From the excerpt below, jemalloc is optimized for allocations less than 512 bytes, while compcache will often want to allocate ~2k. Under compcache, jemalloc would essentially act as a power of 2 slab allocator. It wasn't obvious from skimming the paper whether it would be practical to modify jemalloc to have "quantum-spaced" allocations up to 4k, and I didn't check the source code. http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf page 5 -- Figure 4 shows the size classes for all allocation sizes. Category Subcategory Size Small Tiny 2 B 4 B 8 B Quantum-spaced 16 B 32 B 48 B ... 480 B 496 B 512 B Sub-page 1 kB 2 kB Large 4 kB 8 kB 16 kB ... 256 kB 512 kB 1 MB Huge 2 MB 4 MB 6 MB ... Figure 4: Default size classes, assuming runtime defaults, 4 kB pages and a 16 byte quantum. It would be simpler to have no subcategories for small allocations by doing away with the quantum- spaced size classes. However, most applications primarily allocate objects that are smaller than 512 bytes, and quantum spacing of size classes substantially reduces average internal fragmentation. -- John C. McCabe-Dansted _______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
