Re: [GSOC] HAMMER2 compression feature week7 report

Daniel Flores <[email protected]>
Newsgroups gmane.os.dragonfly-bsd.kernel
Message-ID <CAJcZ+E0uH_SfAwFHM-rZ9=Yr7dqCn9e5mDj6w8eRtdS1BRExfQ@mail.gmail.com>
Hi Samuel,
Thank you for feedback!

On Sun, Aug 4, 2013 at 10:10 PM, Samuel J. Greear <[email protected]> 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.


Daniel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.