makedumpfile 1.5.4, 734G kdump tests
Cliff Wickman
cpw at sgi.com
Fri Jul 12 12:14:27 EDT 2013
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.
-Cliff
--
Cliff Wickman
SGI
cpw at sgi.com
(651) 683-3824
More information about the kexec
mailing list