Re: makedumpfile 1.5.4, 734G kdump tests

Vivek Goyal
2013-07-12T16:42:30Z

On Fri, Jul 12, 2013 at 11:14:27AM -0500, Cliff Wickman wrote:
> On Thu, Jul 11, 2013 at 09:06:47AM -0400, Vivek Goyal wrote:
> > On Tue, Jul 09, 2013 at 11:24:03AM -0500, Cliff Wickman wrote:
> >
> > [..]
> > > UV2000 memory: 734G
> > > makedumpfile: makedumpfile-1.5.4
> > > kexec: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
> > > booted with crashkernel=1G,high crashkernel=192M,low
> > > non-cyclic mode
> > >
> > > write to option init&scan sec. copy sec. dump size
> > > ------------- ----------------- ---- --------- ---------
> > > megaraid disk no compression 19 91 11.7G
> > > megaraid disk zlib compression 20 209 1.4G
> > > megaraid disk snappy compression 20 46 2.4G
> > > megaraid disk snappy compression no mmap 30 72 2.4G
> > > /dev/null no compression 19 28 -
> > > /dev/null zlib compression 19 206 -
> > > /dev/null snappy compression 19 41 -
> > >
> > > Notes and observations
> > > - Snappy compression is a big win over zlib compression; over 4 times faster
> > > with a cost of relatively little disk space.
> >
> > Thanks for the results Cliff. If it is not too much of trouble, can you
> > please also test with lzo compression on same configuration. I am
> > curious to know how much better snappy performs as compared to lzo.
> >
> > Thanks
> > Vivek
>
> Ok. I repeated the tests and included LZO compression.
>
> UV2000 memory: 734G
> makedumpfile: makedumpfile-1.5.4 non-cyclic mode
> kexec: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
> 3.10 kernel with vmcore mmap patches
> booted with crashkernel=1G,high crashkernel=192M,low
>
> write to compression init&scan sec. copy sec. dump size
> ------------- ----------------- ---- --------- ---------
> megaraid disk no compression 20 86 11.6G
> megaraid disk zlib compression 19 209 1.4G
> megaraid disk snappy compression 20 47 2.4G
> megaraid disk lzo compression 19 54 2.8G
>
> /dev/null no compression 19 28 -
> /dev/null zlib compression 20 206 -
> /dev/null snappy compression 19 42 -
> /dev/null lzo compression 20 47 -
>
> Notes:
> - Snappy compression is still be fastest (and more compressed than LZO),
> but LZO is close.
> - Compression and I/O seem pretty well overlapped, so I am not sure that
> multithreading the crash kernel (to speed compression) will speed the
> dump as much I was hoping, unless perhaps the I/O device is an SSD.

Thanks Cliff. So LZO is pretty close to snappy in this case.

Thanks
Vivek