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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 08 May 2010 13:02:33 +0530
From:	Nitin Gupta <ngupta@...are.org>
To:	Pekka Enberg <penberg@...helsinki.fi>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Cyp <cyp561@...il.com>, Minchan Kim <minchan.kim@...il.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Andi Kleen <andi@...stfloor.org>,
	driverdev <devel@...verdev.osuosl.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] ramzswap: Eliminate stale data from compressed memory
 (v2)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/