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
