From: Chao Fan <cfan@redhat.com>
To: "Wenjian Zhou/周文剑" <zhouwj-fnst@cn.fujitsu.com>
Cc: Shaohui Deng <shdeng@redhat.com>, kexec@lists.infradead.org
Subject: Re: [PATCH RFC 00/11] makedumpfile: parallel processing
Date: Tue, 1 Dec 2015 03:39:29 -0500 (EST) [thread overview]
Message-ID: <1831406384.24254782.1448959169018.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <5575123D.8090506@cn.fujitsu.com>
Hi Zhou Wenjian,
I did some tests according to your tables. I have a problem when I set
dump_level to 31. The machine has 1T memory, and when dump_level was set
to 31, the size of vmcore is 17G. The kernel is 3.10.0-327.el7.x86_64.
The kexec-tools is kexec-tools-2.0.7-38.el7.x86_64.
If I use
core_collector time makedumpfile -l --message-level 1 -d 31
in kdump based on makedumpfile 1.5.7, the time is
63 seconds(the average of many tests).
And then I use the kdump based on makedumpfile 1.5.9.
core_collector time makedumpfile -l --message-level 1 -d 31
the time is 58 seconds.
core_collector time makedumpfile --num-threads 1 -l --message-level 1 -d 31
the time is 240 seconds.
core_collector time makedumpfile --num-threads 2 -l --message-level 1 -d 31
the time is 189 seconds.
core_collector time makedumpfile --num-threads 4 -l --message-level 1 -d 31
the time is 220 seconds.
core_collector time makedumpfile --num-threads 8 -l --message-level 1 -d 31
the time is 417 seconds.
core_collector time makedumpfile --num-threads 12 -l --message-level 1 -d 31
the time is 579 seconds.
core_collector time makedumpfile --num-threads 16 -l --message-level 1 -d 31
the time is 756 seconds.
So I do not know why if I add "--num-threads", the makedumpfile will use more
time than without "--num-threads". Since your table also shows that
makedumpfile -d 31, the threads_num is 0, the makdumpfile is fatest.
If there are any problems in my tests, please tell me.
Thanks,
Chao Fan
----- Original Message -----
> From: "Wenjian Zhou/周文剑" <zhouwj-fnst@cn.fujitsu.com>
> To: kexec@lists.infradead.org
> Sent: Monday, June 8, 2015 11:55:41 AM
> Subject: Re: [PATCH RFC 00/11] makedumpfile: parallel processing
>
> hello all,
>
> I test this patch set in two machines and the following is the benchmark.
>
> These tables show the time that makedumpfile spends. And the unit is second.
>
> "core-data" in the table means the context in the vmcore.
> For example:
> core-data's value is 256. It means that in the vmcore, 256 * 8 bits of each
> page
> are set to 1.
>
> "-l" in the table means producing lzo format vmcore
>
> "-c" in the table means producing kdump-compressed format vmcore
>
> ###################################machine with 128G memory
>
> ************ makedumpfile -d 0 ******************
> core-data 256 1280
> threads_num
> -l
> 0 758 881
> 8 932 1014
> 16 973 1085
> -c
> 0 3994 4071
> 8 966 1007
> 16 1053 1192
>
> ************ makedumpfile -d 3 ******************
> core-data 256 1280
> threads_num
> -l
> 0 764 847
> 8 948 1058
> 16 943 1069
> -c
> 0 4021 4050
> 8 949 1029
> 16 1051 1190
>
> ************ makedumpfile -d 31 ******************
> core-data 256 1280
> threads_num
> -l
> 0 4 4
> 8 639 610
> 16 680 680
> -c
> 0 14 13
> 8 607 610
> 16 631 662
>
> ###################################machine with 24G memory
>
> ************ makedumpfile -d 0 ******************
> core-data 0 256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328
> 3584 3840 4096
> threads_num
> -l
> 0 15 140 186 196 196 196 196 197 197 197 195 195 195 195 186 131 15
> 4 9 136 189 204 204 202 201 200 201 200 200 202 204 203 189 136 9
> 8 11 131 193 198 198 202 206 205 206 205 205 202 198 197 193 132 11
> 12 18 137 194 202 203 197 201 203 204 202 201 196 202 202 194 136 17
> -c
> 0 80 786 967 1031 874 849 700 608 652 603 764 768 873 1031 1016 776 80
> 4 82 262 315 321 296 256 255 220 218 221 241 268 303 320 319 259 84
> 8 58 148 174 189 179 189 196 198 199 198 196 190 178 174 170 145 57
> 12 56 112 131 157 170 189 200 204 204 203 199 191 170 157 132 111 59
>
> ************ makedumpfile -d 1 ******************
> core-data 0 256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328
> 3584 3840 4096
> threads_num
> -l
> 0 16 134 194 204 204 205 205 206 205 207 204 203 204 204 193 134 15
> 4 9 132 193 197 196 198 199 200 200 200 199 197 196 197 192 132 9
> 8 12 135 189 202 204 200 197 196 197 195 196 199 203 202 189 136 12
> 12 16 130 190 200 200 205 202 201 200 201 202 205 199 200 189 131 17
> -c
> 0 77 775 1009 1032 872 853 699 606 643 602 758 765 870 1026 1014 774 78
> 4 80 262 316 322 332 257 247 217 223 218 288 256 322 322 315 258 81
> 8 56 146 173 176 170 184 198 205 207 203 198 185 169 180 169 149 56
> 12 56 110 133 152 175 185 194 202 202 202 193 184 176 152 135 114 56
>
> ************ makedumpfile -d 7 ******************
> core-data 0 256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328
> 3584 3840 4096
> threads_num
> -l
> 0 16 138 188 197 197 197 197 197 197 198 196 197 197 197 189 137 16
> 4 10 131 187 202 205 203 202 202 203 203 201 203 204 201 187 131 8
> 8 11 135 191 199 197 201 203 205 206 204 203 200 197 199 192 134 11
> 12 18 134 195 201 203 197 199 202 202 201 199 196 203 201 197 134 19
> -c
> 0 77 770 1011 1032 871 841 698 621 645 601 763 765 870 1025 1014 773 78
> 4 81 263 311 320 319 255 240 216 242 214 240 257 300 319 314 255 80
> 8 57 157 176 172 174 191 196 199 199 199 195 191 173 171 167 146 57
> 12 55 111 136 156 170 188 203 204 204 203 201 186 168 156 136 112 56
>
> ************ makedumpfile -d 31 ******************
> core-data 0 256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328
> 3584 3840 4096
> threads_num
> -l
> 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> 4 7 8 8 8 8 8 8 8 8 8 8 8 8 8 7 8 8
> 8 11 11 11 10 11 11 11 11 11 11 10 11 11 11 11 11 11
> 12 14 13 14 13 13 15 15 13 15 13 14 14 13 15 15 15 16
> -c
> 0 4 4 5 4 4 4 4 4 4 4 4 4 4 4 4 4 4
> 4 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> 8 12 12 12 13 12 12 12 12 12 12 13 12 14 13 12 12 13
> 12 14 16 14 14 13 15 15 15 14 14 14 14 16 14 15 15 14
>
>
> On 06/05/2015 03:56 PM, Zhou Wenjian wrote:
> > This patch set implements parallel processing by means of multiple threads.
> > With this patch set, it is available to use multiple threads to read
> > and compress pages. This parallel process will save time.
> > This feature only supports creating dumpfile in kdump-compressed format
> > from
> > vmcore in kdump-compressed format or elf format. Currently, sadump and
> > xen kdump are not supported.
> >
> > Qiao Nuohan (11):
> > Add readpage_kdump_compressed_parallel
> > Add mappage_elf_parallel
> > Add readpage_elf_parallel
> > Add read_pfn_parallel
> > Add function to initial bitmap for parallel use
> > Add filter_data_buffer_parallel
> > Add write_kdump_pages_parallel to allow parallel process
> > Add write_kdump_pages_parallel_cyclic to allow parallel process in
> > cyclic_mode
> > Initial and free data used for parallel process
> > Make makedumpfile available to read and compress pages parallelly
> > Add usage and manual about multiple threads process
> >
> > Makefile | 2 +
> > erase_info.c | 29 +-
> > erase_info.h | 2 +
> > makedumpfile.8 | 24 +
> > makedumpfile.c | 1505
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > makedumpfile.h | 79 +++
> > print_info.c | 16 +
> > 7 files changed, 1652 insertions(+), 5 deletions(-)
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
>
> --
> Thanks
> Zhou Wenjian
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-12-01 8:39 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 7:56 [PATCH RFC 00/11] makedumpfile: parallel processing Zhou Wenjian
2015-06-05 7:56 ` [PATCH RFC 01/11] Add readpage_kdump_compressed_parallel Zhou Wenjian
2015-06-05 7:56 ` [PATCH RFC 02/11] Add mappage_elf_parallel Zhou Wenjian
2015-06-05 7:56 ` [PATCH RFC 03/11] Add readpage_elf_parallel Zhou Wenjian
2015-06-05 7:56 ` [PATCH RFC 04/11] Add read_pfn_parallel Zhou Wenjian
2015-06-05 7:56 ` [PATCH RFC 05/11] Add function to initial bitmap for parallel use Zhou Wenjian
2015-06-05 7:57 ` [PATCH RFC 06/11] Add filter_data_buffer_parallel Zhou Wenjian
2015-06-05 7:57 ` [PATCH RFC 07/11] Add write_kdump_pages_parallel to allow parallel process Zhou Wenjian
2015-06-05 7:57 ` [PATCH RFC 08/11] Add write_kdump_pages_parallel_cyclic to allow parallel process in cyclic_mode Zhou Wenjian
2015-06-05 7:57 ` [PATCH RFC 09/11] Initial and free data used for parallel process Zhou Wenjian
2015-06-05 7:57 ` [PATCH RFC 10/11] Make makedumpfile available to read and compress pages parallelly Zhou Wenjian
2015-06-05 7:57 ` [PATCH RFC 11/11] Add usage and manual about multiple threads process Zhou Wenjian
2015-06-08 3:55 ` [PATCH RFC 00/11] makedumpfile: parallel processing "Zhou, Wenjian/周文剑"
2015-12-01 8:39 ` Chao Fan [this message]
2015-12-02 5:29 ` "Zhou, Wenjian/周文剑"
2015-12-02 7:24 ` Dave Young
2015-12-02 7:38 ` "Zhou, Wenjian/周文剑"
2015-12-04 2:30 ` Atsushi Kumagai
2015-12-04 3:33 ` "Zhou, Wenjian/周文剑"
2015-12-04 8:56 ` Chao Fan
2015-12-07 1:09 ` "Zhou, Wenjian/周文剑"
2015-12-10 8:14 ` Atsushi Kumagai
2015-12-10 9:36 ` "Zhou, Wenjian/周文剑"
2015-12-10 9:58 ` Chao Fan
2015-12-10 10:32 ` "Zhou, Wenjian/周文剑"
2015-12-10 10:54 ` Chao Fan
2015-12-22 8:32 ` HATAYAMA Daisuke
2015-12-24 2:20 ` Chao Fan
2015-12-24 3:22 ` HATAYAMA Daisuke
2015-12-24 3:31 ` Chao Fan
2015-12-24 3:50 ` HATAYAMA Daisuke
2015-12-24 6:02 ` Chao Fan
2015-12-24 7:22 ` HATAYAMA Daisuke
2015-12-24 8:20 ` Atsushi Kumagai
2015-12-24 9:04 ` Chao Fan
2015-12-14 8:26 ` Atsushi Kumagai
2015-12-14 8:59 ` "Zhou, Wenjian/周文剑"
2015-06-10 6:06 ` Atsushi Kumagai
2015-06-11 3:47 ` "Zhou, Wenjian/周文剑"
2015-06-15 1:59 ` qiaonuohan
2015-06-15 5:57 ` Atsushi Kumagai
2015-06-15 6:06 ` qiaonuohan
2015-06-15 6:07 ` qiaonuohan
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=1831406384.24254782.1448959169018.JavaMail.zimbra@redhat.com \
--to=cfan@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=shdeng@redhat.com \
--cc=zhouwj-fnst@cn.fujitsu.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 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.