From: Jingbai Ma <jingbai.ma@hp.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
vgoyal@redhat.com, ebiederm@xmission.com, cpw@sgi.com,
kumagai-atsushi@mxc.nes.nec.co.jp, "Mitchell,
Lisa (MCLinux in Fort Collins)" <lisa.mitchell@hp.com>,
akpm@linux-foundation.org
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
jingbai.ma@hp.com
Subject: makedumpfile mmap() benchmark
Date: Wed, 27 Mar 2013 13:51:37 +0800 [thread overview]
Message-ID: <515288E9.2070707@hp.com> (raw)
In-Reply-To: <20130214100945.22466.4172.stgit@localhost6.localdomain6>
Hi,
I have tested the makedumpfile mmap patch on a machine with 2TB memory,
here is testing results:
Test environment:
Machine: HP ProLiant DL980 G7 with 2TB RAM.
CPU: Intel(R) Xeon(R) CPU E7- 2860 @ 2.27GHz (8 sockets, 10 cores)
(Only 1 cpu was enabled the 2nd kernel)
Kernel: 3.9.0-rc3+ with mmap kernel patch v3
vmcore size: 2.0TB
Dump file size: 3.6GB
makedumpfile mmap branch with parameters: -c --message-level 23 -d 31
--map-size <map-size>
All measured time from debug message of makedumpfile.
As a comparison, I also have tested with original kernel and original
makedumpfile 1.5.1 and 1.5.3.
I added all [Excluding unnecessary pages] and [Excluding free pages]
time together as "Filter Pages", and [Copyying Data] as "Copy data" here.
makedumjpfile Kernel map-size (KB) Filter pages (s) Copy data (s) Total (s)
1.5.1 3.7.0-0.36.el7.x86_64 N/A 940.28 1269.25 2209.53
1.5.3 3.7.0-0.36.el7.x86_64 N/A 380.09 992.77 1372.86
1.5.3 v3.9-rc3 N/A 197.77 892.27 1090.04
1.5.3+mmap v3.9-rc3+mmap 0 164.87 606.06 770.93
1.5.3+mmap v3.9-rc3+mmap 4 88.62 576.07 664.69
1.5.3+mmap v3.9-rc3+mmap 1024 83.66 477.23 560.89
1.5.3+mmap v3.9-rc3+mmap 2048 83.44 477.21 560.65
1.5.3+mmap v3.9-rc3+mmap 10240 83.84 476.56 560.4
Thanks,
Jingbai Ma
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-03-27 5:51 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-14 10:11 [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore HATAYAMA Daisuke
2013-02-14 10:11 ` [PATCH 01/13] vmcore: allocate buffer for ELF headers on page-size alignment HATAYAMA Daisuke
2013-02-15 15:01 ` Vivek Goyal
2013-02-14 10:11 ` [PATCH 02/13] vmcore: round up buffer size of ELF headers by PAGE_SIZE HATAYAMA Daisuke
2013-02-15 15:18 ` Vivek Goyal
2013-02-18 15:58 ` HATAYAMA Daisuke
2013-02-14 10:11 ` [PATCH 03/13] vmcore: fill unused part of buffer for ELF headers with 0 HATAYAMA Daisuke
2013-02-14 10:12 ` [PATCH 04/13] vmcore: introduce types for objects copied in 2nd kernel HATAYAMA Daisuke
2013-02-15 15:28 ` Vivek Goyal
2013-02-18 16:06 ` HATAYAMA Daisuke
2013-02-19 23:07 ` Vivek Goyal
2013-02-14 10:12 ` [PATCH 05/13] vmcore: modify ELF32 code according to new type HATAYAMA Daisuke
2013-02-15 15:30 ` Vivek Goyal
2013-02-18 16:11 ` HATAYAMA Daisuke
2013-02-14 10:12 ` [PATCH 06/13] vmcore: modify vmcore clean-up function to free buffer on 2nd kernel HATAYAMA Daisuke
2013-02-15 15:32 ` Vivek Goyal
2013-02-14 10:12 ` [PATCH 07/13] vmcore: modify read_vmcore() to read " HATAYAMA Daisuke
2013-02-15 15:51 ` Vivek Goyal
2013-02-14 10:12 ` [PATCH 08/13] vmcore: remove unused helper function HATAYAMA Daisuke
2013-02-15 15:52 ` Vivek Goyal
2013-02-14 10:12 ` [PATCH 09/13] vmcore: copy ELF note segments in buffer on 2nd kernel HATAYAMA Daisuke
2013-02-15 16:53 ` Vivek Goyal
2013-02-18 17:02 ` HATAYAMA Daisuke
2013-02-19 23:05 ` Vivek Goyal
2013-02-14 10:12 ` [PATCH 10/13] vmcore: round-up offset of vmcore object in page-size boundary HATAYAMA Daisuke
2013-02-14 10:12 ` [PATCH 11/13] vmcore: count holes generated by round-up operation for vmcore size HATAYAMA Daisuke
2013-02-14 10:12 ` [PATCH 12/13] vmcore: copy non page-size aligned head and tail pages in 2nd kernel HATAYAMA Daisuke
2013-02-14 10:12 ` [PATCH 13/13] vmcore: introduce mmap_vmcore() HATAYAMA Daisuke
2013-02-15 3:57 ` [PATCH 00/13] kdump, vmcore: support mmap() on /proc/vmcore Atsushi Kumagai
2013-02-18 0:16 ` Hatayama, Daisuke
2013-03-27 5:51 ` Jingbai Ma [this message]
2013-03-27 6:23 ` makedumpfile mmap() benchmark HATAYAMA Daisuke
2013-03-27 6:35 ` Jingbai Ma
-- strict thread matches above, loose matches on Subject: below --
2013-05-03 19:10 Cliff Wickman
2013-05-07 8:47 ` HATAYAMA Daisuke
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=515288E9.2070707@hp.com \
--to=jingbai.ma@hp.com \
--cc=akpm@linux-foundation.org \
--cc=cpw@sgi.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=lisa.mitchell@hp.com \
--cc=vgoyal@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox