On 11/15/2011 04:04 PM, Christoph Hellwig wrote: > Do you have any benchmarks to prove benefits? I recently looked into > using some sort of a slab allocator for xfs_repair, but in the end just > using an efficient threading allocator (tcmalloc) proved to be a) much > faster and b) use less memory. > I am afraid, not yet. But I think it would be faster than raw glibc-based malloc/free. Correct me if I am wrong, because I have a impression that most APP would write its own alloc/free on top of glibc malloc/free. As for tcmalloc, I think it is implementation specific, and just have a quick look at the overview of it, it should be efficient than the simple & dumb slab allocator above. But I think we can only provide tcmalloc as an option to user, since not every one have tcmalloc installed. So even we choose to use tcmalloc, we have to write a wrapper to abstract out tcmalloc and glibc malloc away. Being that said, we need an wrapper interface and the above id = slabs_clsid(object size); # this will preallocate a slab sized by object size. object_ptr = slabs_alloc(id); slabs_free(object_ptr, id); would be an good starting point. Thanks, Yuan |