Re: [GSOC] HAMMER2 compression feature week7 report

[Daniel Flores <daniel5555@xxxxxxxxx>]

--089e0160b5e44e9e0604e335af84
Content-Type: text/plain; charset=ISO-8859-1

Hi Samuel,
Thank you for feedback!

On Sun, Aug 4, 2013 at 10:10 PM, Samuel J. Greear <sjg@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.


Daniel

--089e0160b5e44e9e0604e335af84
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Samuel,<br></div>Thank you for feedback!<br><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Aug 4, 2013 at =
10:10 PM, Samuel J. Greear <span dir=3D"ltr">&lt;<a href=3D"mailto:sjg@evil=
code.net" target=3D"_blank">sjg@evilcode.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Regarding the performa=
nce chart and testing so far, it&#39;s nice to know that the cpu overhead i=
s well-bounded and these small tests likely worked well for simply making s=
ure everything worked, but I wouldn&#39;t spend much/any time on this type =
of testing going forward, since these microbenchmarks only show cached perf=
ormance -- the compressed numbers will basically always look like a net los=
s here (albeit it looks like a small one, which is good) -- the real number=
s of interest are going to be performance of uncached benchmarks / benchmar=
ks that cause a lot of real disk i/o. As you make it stable I would move on=
to things like fsstress, blogbench, bonnie, etc.<br>
</div></div></blockquote><div><br></div><div>Regarding the microbenchmarks,=
 I tried to reduce the effect of caching by reloading hammer2 module betwee=
n each write/read test, so it should only take place on HAMMER partition, b=
ut not on HAMMER2.<br>
</div><div>I&#39;ll definitely do heavy I/O tests in the future.<br></div><=
div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>
</div><div class=3D"gmail_extra"></div><div class=3D"gmail_extra">If the co=
de is stable enough I would be interested to hear what the performance delt=
a is between a pair of dd if=3D/dev/zero bs=3D64k count=3D5000 or similar (=
as long as its much bigger than RAM) with zero-compression on vs off. In th=
eory it should look similar to the delta between cached io and uncached io.=
</div>
</div></blockquote><div><br></div><div>OK, I&#39;m putting this test into m=
y TODO list.<br><br></div><div>Thank you.<br><br><br></div><div>Daniel<br><=
/div></div></div></div>

--089e0160b5e44e9e0604e335af84--