From: Cliff Wickman <cpw@sgi.com>
To: kexec@lists.infradead.org
Cc: d.hatayama@jp.fujitsu.com, kumagai-atsushi@mxc.nes.nec.co.jp
Subject: makedumpfile 1.5.4, 734G kdump tests
Date: Tue, 9 Jul 2013 11:24:03 -0500 [thread overview]
Message-ID: <20130709162403.GA25441@sgi.com> (raw)
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@sgi.com
(651) 683-3824
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next reply other threads:[~2013-07-09 16:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 16:24 Cliff Wickman [this message]
[not found] ` <CAJGZr0JPrBB3cVyVdwJdd6cEUfnXNMuRijb9EOoSy+XmRupv7A@mail.gmail.com>
2013-07-10 9:07 ` makedumpfile 1.5.4, 734G kdump tests HATAYAMA Daisuke
[not found] ` <CAJGZr0L7GBqJHaPzgpFxhpF_jmAZfDJYU_=MFxATxnLk13ni4g@mail.gmail.com>
2013-07-10 18:27 ` Cliff Wickman
2013-07-11 13:06 ` Vivek Goyal
2013-07-12 16:14 ` Cliff Wickman
2013-07-12 16:42 ` Vivek Goyal
2013-07-16 9:22 ` HATAYAMA Daisuke
2013-07-16 14:15 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130709162403.GA25441@sgi.com \
--to=cpw@sgi.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.