From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Seth Jennings <sjenning@linux.vnet.ibm.com>, gregkh@suse.de
Cc: devel@driverdev.osuosl.org, ngupta@vflare.org,
cascardo@holoscopio.com, rdunlap@xenotime.net,
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 0/3] staging: zcache: xcfmalloc support
Date: Wed, 31 Aug 2011 12:46:43 -0700 (PDT) [thread overview]
Message-ID: <6e0e7950-0c91-4bb3-929b-3853fa95e63d@default> (raw)
In-Reply-To: <1314801641-15059-1-git-send-email-sjenning@linux.vnet.ibm.com>
> 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
next prev parent reply other threads:[~2011-08-31 19:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-31 14:40 Seth Jennings
2011-08-31 14:40 ` [PATCH 1/3] staging: zcache: xcfmalloc memory allocator for zcache Seth Jennings
2011-09-01 15:43 ` Seth Jennings
2011-09-06 23:51 ` Greg KH
2011-08-31 14:40 ` [PATCH 2/3] staging: zcache: replace xvmalloc with xcfmalloc Seth Jennings
2011-08-31 14:40 ` [PATCH 3/3] staging: zcache: add zv_page_count and zv_desc_count Seth Jennings
2011-08-31 19:46 ` Dan Magenheimer [this message]
2011-08-31 22:06 ` [PATCH 0/3] staging: zcache: xcfmalloc support Seth Jennings
2011-09-01 15:17 ` Dan Magenheimer
2011-09-01 16:33 ` Seth Jennings
2011-09-01 16:54 ` Dave Hansen
2011-09-01 22:01 ` Seth Jennings
2011-09-01 23:44 ` Dave Hansen
2011-09-01 22:42 ` Seth Jennings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6e0e7950-0c91-4bb3-929b-3853fa95e63d@default \
--to=dan.magenheimer@oracle.com \
--cc=cascardo@holoscopio.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ngupta@vflare.org \
--cc=rdunlap@xenotime.net \
--cc=sjenning@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®