All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: dyoung@redhat.com, kumagai-atsushi@mxc.nes.nec.co.jp,
	kexec@lists.infradead.org, chaowang@redhat.com
Subject: Re: makedumpfile 1.5.0 takes much more time to dump
Date: Mon, 24 Sep 2012 10:51:57 -0400	[thread overview]
Message-ID: <20120924145157.GA14886@redhat.com> (raw)
In-Reply-To: <20120924.095112.153507503.d.hatayama@jp.fujitsu.com>

On Mon, Sep 24, 2012 at 09:51:12AM +0900, HATAYAMA Daisuke wrote:
> From: Vivek Goyal <vgoyal@redhat.com>
> Subject: Re: makedumpfile 1.5.0 takes much more time to dump
> Date: Fri, 21 Sep 2012 09:32:32 -0400
> 
> > On Fri, Sep 21, 2012 at 09:23:57AM +0900, HATAYAMA Daisuke wrote:
> >> From: Vivek Goyal <vgoyal@redhat.com>
> >> Subject: makedumpfile 1.5.0 takes much more time to dump
> >> Date: Thu, 20 Sep 2012 16:06:34 -0400
> >> 
> >> > Hi Atsushi san,
> >> > 
> >> > We tried makedumpfile 1.5.0 on a 1TB machine and it seems to regress
> >> > badly. We reserved 192MB of memory and following are test results.
> >> > 
> >> > #1. makedumpfile-1.4.2 -E --message-level 1 -d 31
> >> > real     3m47.520s
> >> > user     0m56.543s
> >> > sys	 2m41.631s
> >> > 
> >> > #2. makedumpfile-1.5.0 -E --message-level 1 -d 31
> >> > real     52m25.262s
> >> > user     32m51.310s
> >> > sys	 18m53.265s
> >> > 
> >> > #3. makedumpfile-1.4.2 -c --message-level 1 -d 31
> >> > real     8m49.107s
> >> > user     4m34.180s
> >> > sys	 4m8.691s
> >> > 
> >> > #4. makedumpfile-1.5.0 -c --message-level 1 -d 31
> >> > real     46m48.985s
> >> > user     29m35.203s
> >> > sys	 16m43.149s
> >> > 
> >> 
> >> Hello Vivek,
> >> 
> >> On v1.5.0 we cannot filter free pages in constant space becuase we
> >> have yet to test it. Instead, the existing method is used here, which
> >> repeats walking on a whole page frames the number of cycles times.
> >> 
> >> As Kumagai-san explains, the number of cycles can be calculated by the
> >> following expression:
> >> 
> >>   N = physical memory size / (page size * bit per byte(8) * BUFSIZE_CYCLIC)
> >> 
> >> So,
> >> 
> >>   N = 2TB / (4KB * 8 * 1MB) = 64 cycles.
> >> 
> >> I guess on this environment, it took about 50 seconds to filter free
> >> pages in one cycle.
> > 
> > Ok, so once we have your walking through page struct patches in, hopefully
> > this problem will be gone?
> > 
> 
> Yes, then free page filtering is integrated in other mem_map array
> logics. You can see how it takes from the following message.
> 
> Excluding unnecessary pages        : [100 %] STEP [Excluding unnecessary pages] : 0.204574 seconds
> 
> New logic takes equal to or quicker than the total time indicated by
> the above kind of messages now.
> 
> > If that's going to take time, can we make using of new logic conditional
> > on a command line option. So that user has the option of using old
> > logic.
> > 
> 
> Kumagai-san should decide this. 

Ok, thanks a lot for testing and information. Kumagai-san is on vacation
till sept 30. So I will wait for the response.

Thanks
Vivek

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

  reply	other threads:[~2012-09-24 14:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-20 20:06 makedumpfile 1.5.0 takes much more time to dump Vivek Goyal
2012-09-21  0:23 ` HATAYAMA Daisuke
2012-09-21  0:43   ` HATAYAMA Daisuke
2012-09-21 13:32   ` Vivek Goyal
2012-09-24  0:51     ` HATAYAMA Daisuke
2012-09-24 14:51       ` Vivek Goyal [this message]
2012-10-03  7:38         ` Atsushi Kumagai
2012-10-03 12:48           ` Vivek Goyal
2012-10-04  1:36             ` HATAYAMA Daisuke
2012-10-04  1:15           ` HATAYAMA Daisuke
     [not found] <1350912018.13097.54.camel@lisamlinux.fc.hp.com>
2012-10-24  7:45 ` Atsushi Kumagai
2012-10-25 11:09   ` Lisa Mitchell
2012-11-06  3:37     ` 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=20120924145157.GA14886@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=dyoung@redhat.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.