Introduction

How does its performance compares to TLSF? Is it faster? Is there any gain using it instead of TLSF? Are there any benchmarks comparing both allocators? When will it come to compcache-0.4? Will we have benchmarks comparing performance of before/after this new allocator?

I haven't yet done comparison with TLSF. Also, don't know when I will integrate this with compcache. I'll try to get some benchmarks once this is ported to kernel.

Will you try to get compcache merged in 2.6.28?

Not yet done speed tests, but xvMalloc is almost same as TLSF wrt space efficiency (almost always 1-2% better than TLSF). I plan to do speed tests soon (there shouldn't be any difference).

Not sure when I will push it for mainline.

A novice question, as I understand, xvMalloc is a pool based allocator. Can xvMalloc be used as a general purpose allocator replacing kmalloc in case my kernel driver does many smaller but mostly similar sized allocations? I have gone through the doc which compares xvMalloc with SLOB and SLUB, I think it fits the bill in case.

I am going through the code currently, does xvMalloc take care of adjusting memory allocations from appropriate zones depending on the memory pressure? E.g. allocate from zone high mem only if zone normal is depleted etc?

As curiosity, I was just trying to compare Jemalloc Linux port and xvMalloc user port. Jemalloc claims very good performance in most cases and guarantees very less fragmentation. Did you evaluate it earlier?

> As curiosity, I was just trying to compare Jemalloc Linux port and xvMalloc user port. Jemalloc claims very good performance in most cases and guarantees very less fragmentation. Did you evaluate it earlier?

The case against jemalloc was clearly explained by John. Copying his response here: ---

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.