[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