makedumpfile 1.5.4, 734G kdump tests

Cliff Wickman cpw at sgi.com
Tue Jul 9 12:24:03 EDT 2013


I have run some tests with the latest makedumpfile and kexec and the
results (below) look very good to me.

This particular test machine has a megaraid root, which had been a problem
with previous kexec-tools (I did have to allocate a lot of low memory).

My 3.10 kernel does have Hatayama's vmcore mmap patches.

My only remaining concern for makedumpfile is the filtering of huge pages.
I believe that patch is in progress; but I don't see it in 1.5.4.

-Cliff


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.
- The vmcore mmap kernel patch cuts off about 1/3 of both page scan time and
  data copy time.
  I hope those patches reach Linus' tree shortly, as you expect.
- Data copy time is dominated by compression time; writing compressed data
  to /dev/null uses almost the same time as writing to disk.
  I hope your efforts to multi-thread the crash kernel go forward.

-- 
Cliff Wickman
SGI
cpw at sgi.com
(651) 683-3824



More information about the kexec mailing list