All of lore.kernel.org
 help / color / mirror / Atom feed
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH] makedumpfile: print spinner in progress information
Date: Tue, 29 Oct 2013 10:26:08 +0900	[thread overview]
Message-ID: <526F0EB0.20600@jp.fujitsu.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE971B8EE2@BPXM01GP.gisp.nec.co.jp>

(2013/10/25 13:07), Atsushi Kumagai wrote:
> Hello HATAYAMA-san,
> 
> (2013/10/25 9:55), HATAYAMA Daisuke wrote:
>> 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 adds spinner that rotates in the
>> order of /, |, \ and - next to the progress indicator in percentage,
>> which helps users to get aware that system is still active and crash
>> dump process is still in progress now.
>>
>> This code is borrowed from diskdump code.
>>
>> The example is like this:
>>
>> Copying data                       : [  0 %] /
>> Copying data                       : [  8 %] |
>> Copying data                       : [ 11 %] \
>> Copying data                       : [ 14 %] -
>> Copying data                       : [ 16 %] /
>> ...
>> Copying data                       : [ 99 %] /
>> Copying data                       : [100 %] |
> 
> I like it, but have a comment.
> 
>      6109 int
>      6110 write_kdump_pages_cyclic(struct cache_data *cd_header, struct cache_data *cd_page,
>      6111                          struct page_desc *pd_zero, off_t *offset_data)
>      6112 {
>      ...
>      6156         per = info->num_dumpable / 100;
>      ...
>      6178         for (pfn = start_pfn; pfn < end_pfn; pfn++) {
>      6179
>      6180                 if ((num_dumped % per) == 0)
>      6181                         print_progress(PROGRESS_COPY, num_dumped, info->num_dumpable);
> 
> The interval of calling print_progress() looks still long if
> num_dumpable is huge.
> So how about fix this, e.g., by changing the interval to time based ?
> 

I wrote simple bench for time-based interval as below, which measures
total time consumed for calling time system call with/without vDSO.
It seems to me that both results are acceptable.
I'll reflect this change in next version.

$ ./bench
total: 21.059131
average: 0.000000
total: 65.558263
average: 0.000000

==bench.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

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;

        for (i = 0; i < nr_repeat; ++i) {
                t1 = getdtime();
                time(&t);
                t2 = getdtime();
                total += t2 - t1;
        }
        printf("total: %lf\n", total);
        printf("average: %lf\n", total / nr_repeat);

        for (i = 0; i < nr_repeat; ++i) {
                t1 = getdtime();
                syscall(NR_time, &t);
                t2 = getdtime();
                total += t2 - t1;
        }
        printf("total: %lf\n", total);
        printf("average: %lf\n", total / nr_repeat);

        return 0;
}
==

-- 
Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2013-10-29  1:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25  1:45 [PATCH] makedumpfile: print spinner in progress information HATAYAMA Daisuke
2013-10-25  2:57 ` Jingbai Ma
2013-10-25  3:03   ` Jingbai Ma
2013-10-29  0:57     ` HATAYAMA Daisuke
2013-10-25  4:07 ` Atsushi Kumagai
2013-10-29  1:26   ` HATAYAMA Daisuke [this message]
2013-10-29  2:42     ` HATAYAMA Daisuke
2013-10-29  4:50       ` Atsushi Kumagai

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=526F0EB0.20600@jp.fujitsu.com \
    --to=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.