Re: [PATCH 2/3]: xvmalloc memory allocator

[Nitin Gupta]

(sending again since it was blocked by lkml last time. Sorry Christoph for duplicate email).

Christoph Lameter wrote:
> On Tue, 17 Mar 2009, Nitin Gupta wrote:
>
> > Slub allocator could not be used due to fragmentation issues:
> > http://code.google.com/p/compcache/wiki/AllocatorsComparison
> > Data here shows kmalloc using ~43% more memory than TLSF and xvMalloc
> > is showed ~2% more space efficiency than TLSF (due to smaller metadata).
>
> Well this looks like the use of 2^n sizes of the kmalloc arrayse cause a
> lot of wastage here. Creating slab caches that fit your needs may help?

Creating slabs for sizes in range, say, [32, 3/4*PAGE_SIZE] separated by 64bytes
will require 48 slabs! Then for slab of each size class will have wastage due to
unused slab objects in each class.
Larger difference in slab sizes (and thus small no. of them), will surely cause too much
wastage due to internal fragmentation.

Another (more important) point to consider is that, use of slabs will eat-up vmalloc
area to keep slab memory backed by VA space. On 32-bit systems, vmalloc area
is small and limits amount of memory that can be allocated for compressed pages.
With xvmalloc we map/unmap pages on demand thus removing dependence on
vmalloc VA area.

> Have you had a look at the SLOB approach?
>

Nope. I will see how this may help.

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/