linux-kernel - Re: [PATCH v2 0/3] staging: zcache: xcfmalloc support

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 09 Sep 2011 22:41:31 -0400
From:	Nitin Gupta <ngupta@...are.org>
To:	Greg KH <greg@...ah.com>
CC:	Seth Jennings <sjenning@...ux.vnet.ibm.com>, gregkh@...e.de,
	devel@...verdev.osuosl.org, dan.magenheimer@...cle.com,
	cascardo@...oscopio.com, linux-kernel@...r.kernel.org,
	dave@...ux.vnet.ibm.com, linux-mm@...ck.org,
	brking@...ux.vnet.ibm.com, rcj@...ux.vnet.ibm.com
Subject: Re: [PATCH v2 0/3] staging: zcache: xcfmalloc support

On 09/09/2011 04:34 PM, Greg KH wrote:

> On Wed, Sep 07, 2011 at 09:09:04AM -0500, Seth Jennings wrote:
>> Changelog:
>> v2: fix bug in find_remove_block()
>>     fix whitespace warning at EOF
>>
>> This patchset introduces a new memory allocator for persistent
>> pages for zcache.  The current allocator is xvmalloc.  xvmalloc
>> has two notable limitations:
>> * High (up to 50%) external fragmentation on allocation sets > PAGE_SIZE/2
>> * No compaction support which reduces page reclaimation
> 
> I need some acks from other zcache developers before I can accept this.
> 

First, thanks for this new allocator; xvmalloc badly needed a replacement :)

I went through xcfmalloc in detail and would be posting detailed
comments tomorrow.  In general, it seems to be quite similar to the
"chunk based" allocator used in initial implementation of "compcache" --
please see section 2.3.1 in this paper:
http://www.linuxsymposium.org/archives/OLS/Reprints-2007/briglia-Reprint.pdf

I'm really looking forward to a slab based allocator as I mentioned in
the initial mail:
http://permalink.gmane.org/gmane.linux.kernel.mm/65467

With the current design xcfmalloc suffers from issues similar to the
allocator described in the paper:
 - High metadata overhead
 - Difficult implementation of compaction
 - Need for extra memcpy()s  etc.

With slab based approach, we can almost eliminate any metadata overhead,
remove any free chunk merging logic, simplify compaction and so on.

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/