linux-kernel - RE: [PATCH 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]

Message-ID: <6e0e7950-0c91-4bb3-929b-3853fa95e63d@default>
Date:	Wed, 31 Aug 2011 12:46:43 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>, gregkh@...e.de
Cc:	devel@...verdev.osuosl.org, ngupta@...are.org,
	cascardo@...oscopio.com, rdunlap@...otime.net,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH 0/3] staging: zcache: xcfmalloc support

> 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
> 
> xcfmalloc seeks to fix these issues by using scatter-gather model that
> allows for cross-page allocations and relocatable data blocks.
> 
> In tests, with pages that only compress to 75% of their original
> size, xvmalloc had an effective compression (pages stored / pages used by the
> compressed memory pool) of ~95% (~20% lost to fragmentation). Almost nothing
> was gained by the compression in this case. xcfmalloc had an effective
> compression of ~77% (about ~2% lost to fragmentation and metadata overhead).

Hi Seth --

Do you have any data comparing xcfmalloc vs xvmalloc for
compression ratio and/or performance (cycles to compress
or decompress different pages) on a wide(r) range of data?
Assuming xcfmalloc isn't "always better", maybe it would
be best to allow the algorithm to be selectable?  (And
then we would also need to decide the default.)

(Hopefully Nitin will have a chance to comment, since he
has much more expertise in compression than I do.)

Thanks,
Dan
--
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/