Re: [PATCH 2/3] xvmalloc memory allocator

From: Nitin Gupta
Date: Fri Mar 20 2009 - 15:45:21 EST


Pekka Enberg wrote:
On 3/20/2009, "Christoph Lameter" <cl@xxxxxxxxxxxxxxxxxxxx> wrote:
I think, with a bit playing around with interfaces, it can be turned into
general purpose allocator (this will most probably lack highmem support).
Then it would need to implement the SLAB api (see include/linux/slab.h).
Thus we are getting slab allocator #5.

I do not see the point in that. As I suggested earlier, you should
probably just move this into drivers/block/ and make it a private
compcache allocator.


Your wish. But, really, we should not dismiss an O(1) allocator with great
space-efficiency so easily. I think it will be great at least for embedded
devices (its counterpart, SLOB is simply funny).

Just to add to this, Xen recently included a variant of TLSF allocator
which was used in earlier versions of compcache. TLSF is allocator on
which xvmalloc is based.
http://xenbits.xensource.com/xen-unstable.hg?file/0477f9061c8a/xen/common/xmalloc_tlsf.c
(Though I do not know which parts of xen depend on this allocator).

and xvmalloc vs tlsf arguments are here:
http://code.google.com/p/compcache/wiki/xvMalloc

tlsf:
http://rtportal.upv.es/rtmalloc/

Anyways, I will move it to drivers/block.

Thanks,
Nitin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/