[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E84AF30.30402@linux.vnet.ibm.com>
Date: Thu, 29 Sep 2011 12:47:28 -0500
From: Seth Jennings <sjenning@...ux.vnet.ibm.com>
To: Seth Jennings <sjenning@...ux.vnet.ibm.com>
CC: gregkh@...e.de, dan.magenheimer@...cle.com, ngupta@...are.org,
cascardo@...oscopio.com, devel@...verdev.osuosl.org,
linux-kernel@...r.kernel.org, rdunlap@...otime.net,
linux-mm@...ck.org, rcj@...ux.vnet.ibm.com,
dave@...ux.vnet.ibm.com, brking@...ux.vnet.ibm.com
Subject: Re: [PATCH v2 0/3] staging: zcache: xcfmalloc support
On 09/07/2011 09:09 AM, Seth Jennings wrote:
>
> I did some quick tests with "time" using the same program and the
> timings are very close (3 run average, little deviation):
>
> xvmalloc:
> zero filled 0m0.852s
> text (75%) 0m14.415s
>
> xcfmalloc:
> zero filled 0m0.870s
> text (75%) 0m15.089s
>
> I suspect that the small decrease in throughput is due to the
> extra memcpy in xcfmalloc. However, these timing, more than
> anything, demonstrate that the throughput is GREATLY effected
> by the compressibility of the data.
This is not correct. I found out today that the reason text
compressed so much more slowly is because my test program
was inefficiently filling text filled pages.
With my corrected test program:
xvmalloc:
zero filled 0m0.751s
text (75%) 0m2.273s
It is still slower on less compressible data but not to the
degree previously stated.
I don't have the xcfmalloc numbers yet, but I expect they are
almost the same.
--
Seth
--
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/
Powered by blists - more mailing lists