[linux-mm-cc] Fwd: [RFC][PATCH 0/6] compcache: Compressed Caching

Nai Xia nai.xia at gmail.com
Sat Apr 12 08:50:04 EDT 2008


On Thu, Apr 10, 2008 at 12:04 AM, Nitin Gupta <nitingupta910 at gmail.com> wrote:
> ---------- Forwarded message ----------
>  From: Andrew Morton <akpm at linux-foundation.org>
>  Date: Wed, Apr 9, 2008 at 8:17 AM
>  Subject: Re: [RFC][PATCH 0/6] compcache: Compressed Caching
>  To: nitingupta910 at gmail.com
>  Cc: linux-mm at kvack.org
>
>  On Fri, 21 Mar 2008 01:29:58 +0530 Nitin Gupta <nitingupta910 at gmail.com> wrote:
>   > For general desktop use, this is giving *significant* performance gain
>   > under memory pressure. For now, it has been tested only on x86.
>
>
>  <snip>
>
>   The values of "*significant*" should be exhaustively documented in the
>   patch changelogs. That is 100%-the-entire-whole-point of the patchset!
>   Omitting that information tends to reduce the number of C's.
>
>  </snip>
>
>  <End>
>
>
>
>  So, I will require performance numbers to justify inclusion of compcache
>  in mainline. We already have separate perf numbers for lzo(compressor) and
>  tlsf(allocator) but none that shows that using compcache is good for
>  perf under memory pressure.
>
>  If anyone is willing to take up this task, you can refer this paper:
>  http://ols.108.redhat.com/2007/Reprints/briglia-Reprint.pdf

I'd like to help, and
1. do you think the benchmark from memtest is enough convincing?
shall we introduce some additional tests?
2. I plan to use a x86 destop, is it ok? or does the Compressed Caching
focus mainly on embedded systems?

>
>  This paper shows benchmarks of previous implementation of memory compression.
>  It will give good idea on what to measure.
>
>
>  Thanks,
>  Nitin
>  _______________________________________________
>  linux-mm-cc mailing list
>  linux-mm-cc at lists.laptop.org
>  http://lists.laptop.org/listinfo/linux-mm-cc
>

Best Regards,
Nai


More information about the linux-mm-cc mailing list