[GSOC] HAMMER2 compression feature week7 report

Daniel Flores daniel5555 at gmail.com
Mon Aug 5 09:20:20 PDT 2013

Hi Samuel,
Thank you for feedback!

On Sun, Aug 4, 2013 at 10:10 PM, Samuel J. Greear <sjg at evilcode.net> wrote:

> Regarding the performance chart and testing so far, it's nice to know that
> the cpu overhead is well-bounded and these small tests likely worked well
> for simply making sure everything worked, but I wouldn't spend much/any
> time on this type of testing going forward, since these microbenchmarks
> only show cached performance -- the compressed numbers will basically
> always look like a net loss here (albeit it looks like a small one, which
> is good) -- the real numbers of interest are going to be performance of
> uncached benchmarks / benchmarks that cause a lot of real disk i/o. As you
> make it stable I would move onto things like fsstress, blogbench, bonnie,
> etc.

Regarding the microbenchmarks, I tried to reduce the effect of caching by
reloading hammer2 module between each write/read test, so it should only
take place on HAMMER partition, but not on HAMMER2.
I'll definitely do heavy I/O tests in the future.

> If the code is stable enough I would be interested to hear what the
> performance delta is between a pair of dd if=/dev/zero bs=64k count=5000 or
> similar (as long as its much bigger than RAM) with zero-compression on vs
> off. In theory it should look similar to the delta between cached io and
> uncached io.

OK, I'm putting this test into my TODO list.

Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130805/3e1bc1bd/attachment-0003.htm>

More information about the Kernel mailing list