Re: [PATCH 0/3] ramzswap: Eliminate stale data from compressed memory(v2)

[Nitin Gupta]

On 05/08/2010 12:56 PM, Pekka Enberg wrote:
> Nitin Gupta wrote:
>> Oops, missed this part:
>>
>> On 05/08/2010 11:59 AM, Pekka Enberg wrote:
>>> Andrew Morton wrote:
>>>> I've completely forgotten why we need this xvmalloc thing and I don't
>>>> recall whether we decided it would be a good thing to have as a generic
>>>> facility and of course it's all unexplained and undocumented.  I won't
>>>> be looking at it today, for this reason.
>>> We need it because the slab allocator is not a good fit for this special
>>> purpose driver due to fragmentation. Nitin, you had a nice web page
>>> showing all the relevant numbers but I can't find it anymore.
>>>
>>
>> xvmalloc performance numbers:
>> http://code.google.com/p/compcache/wiki/xvMalloc
>> http://code.google.com/p/compcache/wiki/xvMallocPerformance
> 
> I don't see the xvmalloc vs. kmalloc fragmentation numbers there. I
> thought you had some?
> 

TLSF vs kmalloc (SLUB):
http://code.google.com/p/compcache/wiki/AllocatorsComparison

By design, xvmalloc is very similar to TLSF. In fact, xvmalloc has less
metadata overhead than TLSF. So, we will surely get similar results for
xvmalloc vs kmalloc comparison too.

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/