[kexec-tools] makedumpfile: Improve progress information for huge memory system.
WANG Chao
wangchao at fedoraproject.org
Wed Jan 22 04:56:13 UTC 2014
commit b085004c23033d31470191e64ec2bdb348bd147d
Author: Baoquan He <bhe at redhat.com>
Date: Fri Jan 17 17:39:35 2014 +0800
makedumpfile: Improve progress information for huge memory system.
Backport from upstream.
commit 20ecc0827e7837c52f3903638a59959f8bf17f9e
Author: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
Date: Tue Nov 5 00:29:35 2013 +0900
[PATCH v2] Improve progress information for huge memory system.
On system with huge memory, percentage in progress information is
updated at very slow interval, because 1 percent on 1 TiB memory is
about 10 GiB, which looks like as if system has freezed. Then,
confused users might get tempted to push a reset button to recover the
system. We want to avoid such situation as much as possible.
Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
Signed-off-by: Baoquan He <bhe at redhat.com>
Acked-by: Vivek Goyal <vgoyal at redhat.com>
...prove-progress-information-for-huge-memor.patch | 200 ++++++++++++++++++++
kexec-tools.spec | 2 +
2 files changed, 202 insertions(+), 0 deletions(-)
---
diff --git a/kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch b/kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch
new file mode 100644
index 0000000..9b15185
--- /dev/null
+++ b/kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch
@@ -0,0 +1,200 @@
+From 20ecc0827e7837c52f3903638a59959f8bf17f9e Mon Sep 17 00:00:00 2001
+From: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
+Date: Tue, 5 Nov 2013 00:29:35 +0900
+Subject: [PATCH] [PATCH v2] Improve progress information for huge memory
+ system.
+
+On system with huge memory, percentage in progress information is
+updated at very slow interval, because 1 percent on 1 TiB memory is
+about 10 GiB, which looks like as if system has freezed. Then,
+confused users might get tempted to push a reset button to recover the
+system. We want to avoid such situation as much as possible.
+
+To address the issue, this patch:
+
+- increases the number of calling print_progress() from once in
+ (written pages / 100)-pages to once in (written pages /
+ 10000)-pages,
+
+- extends precision in progress information by adding 1 digit to its
+ fractional part, and
+
+- adds spinner that rotates in the order of /, |, \ and - in next to
+ the progress indicator in percentage,
+
+which help users to get aware that system is still active and crash
+dump process is still in progress now.
+
+The spinner code is borrowed from diskdump code.
+
+The ouput is changed from:
+
+Copying data : [ 0 %] /
+Copying data : [ 8 %] |
+Copying data : [ 11 %] \
+Copying data : [ 14 %] -
+Copying data : [ 16 %] /
+...
+Copying data : [ 99 %] /
+Copying data : [100 %] |
+
+to:
+
+Copying data : [ 0.1 %] /
+Copying data : [ 8.9 %] |
+Copying data : [ 11.6 %] \
+Copying data : [ 14.3 %] -
+Copying data : [ 16.4 %] /
+...
+Copying data : [ 99.2 %] /
+Copying data : [100.0 %] |
+
+This patch doesn't adopt purely time-based approach that records the
+time when print_progress() is called at each invocation and print the
+recorded time if it is strictly larger than the previous time value.
+
+The problem is that calling time() system call amounts to
+considertably long time in total on huge memory system. For example,
+here is a simple bench that measures total execution time of time()
+system call for (1TiB / 4KiB)-times:
+
+$ ./bench
+total: 18.360503
+total: 34.910297
+
+the result of which reveals that it amounts to about 20 seconds with
+vDSO optimization and about 35 seconds without.
+
+BTW, on our 12 TiB memory system, we collect about 300 GiB crash dump
+in about 40 minutes with dump level 31. On 12TiB, the benchmark result
+corresponds to about 4 minutes and 7 minutes respectively, both of which
+affects a whole performance.
+
+==bench.c
+static inline double getdtime(void)
+{
+ struct timeval tv;
+ gettimeofday(&tv, NULL);
+ return (double)tv.tv_sec + (double)tv.tv_usec * 1.0e-6;
+}
+
+int main(int argc, char **argv)
+{
+ unsigned long i;
+ time_t t;
+ double t1, t2, total;
+ const int NR_time = 201;
+ const unsigned long nr_repeat = (1UL << 40) / 4096;
+
+ total = 0;
+ for (i = 0; i < nr_repeat; ++i) {
+ t1 = getdtime();
+ time(&t);
+ t2 = getdtime();
+ total += t2 - t1;
+ }
+ printf("total: %lf\n", total);
+
+ total = 0;
+ for (i = 0; i < nr_repeat; ++i) {
+ t1 = getdtime();
+ syscall(NR_time, &t);
+ t2 = getdtime();
+ total += t2 - t1;
+ }
+ printf("total: %lf\n", total);
+
+ return 0;
+}
+==
+
+Signed-off-by: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
+---
+ makedumpfile.c | 8 ++++----
+ print_info.c | 15 +++++++++------
+ 2 files changed, 13 insertions(+), 10 deletions(-)
+
+diff --git a/makedumpfile-1.5.4/makedumpfile.c b/makedumpfile-1.5.4/makedumpfile.c
+index dafe83b..3746cf6 100644
+--- a/makedumpfile-1.5.4/makedumpfile.c
++++ b/makedumpfile-1.5.4/makedumpfile.c
+@@ -5573,7 +5573,7 @@ write_elf_pages(struct cache_data *cd_header, struct cache_data *cd_page)
+ initialize_2nd_bitmap(&bitmap2);
+
+ num_dumpable = get_num_dumpable();
+- per = num_dumpable / 100;
++ per = num_dumpable / 10000;
+
+ off_seg_load = info->offset_load_dumpfile;
+ cd_page->offset = info->offset_load_dumpfile;
+@@ -5858,7 +5858,7 @@ write_elf_pages_cyclic(struct cache_data *cd_header, struct cache_data *cd_page)
+ return FALSE;
+
+ num_dumpable = info->num_dumpable;
+- per = num_dumpable / 100;
++ per = num_dumpable / 10000;
+
+ off_seg_load = info->offset_load_dumpfile;
+ cd_page->offset = info->offset_load_dumpfile;
+@@ -6116,7 +6116,7 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data *cd_page)
+ }
+
+ num_dumpable = get_num_dumpable();
+- per = num_dumpable / 100;
++ per = num_dumpable / 10000;
+
+ /*
+ * Calculate the offset of the page data.
+@@ -6317,7 +6317,7 @@ write_kdump_pages_cyclic(struct cache_data *cd_header, struct cache_data *cd_pag
+ goto out;
+ }
+
+- per = info->num_dumpable / 100;
++ per = info->num_dumpable / 10000;
+
+ /*
+ * Set a fileoffset of Physical Address 0x0.
+diff --git a/makedumpfile-1.5.4/print_info.c b/makedumpfile-1.5.4/print_info.c
+index 3527970..d7a8600 100644
+--- a/makedumpfile-1.5.4/print_info.c
++++ b/makedumpfile-1.5.4/print_info.c
+@@ -283,27 +283,30 @@ print_usage(void)
+ void
+ print_progress(const char *msg, unsigned long current, unsigned long end)
+ {
+- int progress;
++ float progress;
+ time_t tm;
+ static time_t last_time = 0;
++ static unsigned int lapse = 0;
++ static const char *spinner = "/|\\-";
+
+ if (current < end) {
+ tm = time(NULL);
+ if (tm - last_time < 1)
+ return;
+ last_time = tm;
+- progress = current * 100 / end;
++ progress = (float)current * 100 / end;
+ } else
+ progress = 100;
+
+ if (flag_ignore_r_char) {
+- PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%3d %%]\n",
+- msg, progress);
++ PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%5.1f %%] %c\n",
++ msg, progress, spinner[lapse % 4]);
+ } else {
+ PROGRESS_MSG("\r");
+- PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%3d %%] ",
+- msg, progress);
++ PROGRESS_MSG("%-" PROGRESS_MAXLEN "s: [%5.1f %%] %c",
++ msg, progress, spinner[lapse % 4]);
+ }
++ lapse++;
+ }
+
+ void
+--
+1.8.3.1
+
diff --git a/kexec-tools.spec b/kexec-tools.spec
index cf890b2..c7a931b 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -95,6 +95,7 @@ Patch614: kexec-tools-2.0.4-makedumpfile-Add-help-and-man-message-for-help.patch
Patch615: kexec-tools-2.0.4-makedumpfile-Add-non-mmap-option-to-disable-mmap-manually.patch
Patch616: kexec-tools-2.0.4-makedumpfile-Fall-back-to-read-when-mmap-fails.patch
Patch617: kexec-tools-2.0.4-vmcore-dmesg-struct_val_u64-not-casting-u64-to-u32.patch
+Patch618: kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch
%description
kexec-tools provides /sbin/kexec binary that facilitates a new
@@ -143,6 +144,7 @@ tar -z -x -v -f %{SOURCE19}
%patch615 -p1
%patch616 -p1
%patch617 -p1
+%patch618 -p1
tar -z -x -v -f %{SOURCE13}
More information about the scm-commits
mailing list