All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: d.hatayama@jp.fujitsu.com, kexec@lists.infradead.org
Subject: Re: [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption.
Date: Wed, 15 Aug 2012 09:31:03 -0400	[thread overview]
Message-ID: <20120815133102.GA17033@redhat.com> (raw)
In-Reply-To: <20120815152710.982b745a50673defdf9aabd1@mxc.nes.nec.co.jp>

On Wed, Aug 15, 2012 at 03:27:10PM +0900, Atsushi Kumagai wrote:

[..]
> > >> 
> > >> STEP [Excluding free pages       ] : 49.846321 seconds
> > >> STEP [Excluding unnecessary pages] : 6.339228 seconds
> > >> STEP [Excluding free pages       ] : 48.595884 seconds
> > >> STEP [Excluding unnecessary pages] : 6.530479 seconds
> > >> STEP [Excluding free pages       ] : 48.598879 seconds
> > >> STEP [Excluding unnecessary pages] : 6.527133 seconds
> > >> STEP [Excluding free pages       ] : 48.602401 seconds
> > >> STEP [Excluding unnecessary pages] : 6.502681 seconds
> > >> STEP [Excluding free pages       ] : 48.602010 seconds
> > >> STEP [Excluding unnecessary pages] : 6.469853 seconds
> > >> STEP [Excluding free pages       ] : 48.601637 seconds
> > >> STEP [Excluding unnecessary pages] : 6.431381 seconds
> > >> STEP [Excluding free pages       ] : 48.601195 seconds
> > >> STEP [Excluding unnecessary pages] : 6.416676 seconds
> > >> STEP [Excluding free pages       ] : 48.602221 seconds
> > >> STEP [Excluding unnecessary pages] : 6.387611 seconds
> > >> STEP [Excluding free pages       ] : 48.589972 seconds
> > >> STEP [Excluding unnecessary pages] : 0.816955 seconds
> > > 
> > > So what does above represent. Each step is taking 48 seconds or total
> > > time taken to filter vmcore is 48 seconds? What's the buffer size used
> > > here.
> > > 
> > 
> > The free_list logic always filteres a whole memory range even if the
> > range we need to filter is only a cerntain part, so it took about 48
> > seconds at each cycle.
> 
> It seems that the mem_map array logic is effective especially in large machine.
> I'll review your mem_map array patchset after the next version is released.

Yes please review and merge mem_map array changes also. This seems to be
resulting in signifacnt saving. According to numbers above, looks like it cuts
down filtering time by 9 times.

Thanks
Vivek

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

  reply	other threads:[~2012-08-15 13:31 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-29  2:13 [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption Atsushi Kumagai
2012-06-29  2:16 ` [RFC PATCH v2 1/10] Add flag to enable cyclic processing Atsushi Kumagai
2012-06-29  2:17 ` [RFC PATCH v2 2/10] Prepare partial bitmap for " Atsushi Kumagai
2012-06-29  2:17 ` [RFC PATCH v2 3/10] Change the function related to excluding unnecessary pages Atsushi Kumagai
2012-06-29  2:18 ` [RFC PATCH v2 4/10] Add function to update target region Atsushi Kumagai
2012-06-29  2:19 ` [RFC PATCH v2 5/10] Add function to get num_dumpable for cyclic processing Atsushi Kumagai
2012-06-29  2:21 ` [RFC PATCH v2 6/10] Implement the main routine of cyclic processing for kdump-compressed format Atsushi Kumagai
2012-06-29  2:22 ` [RFC PATCH v2 7/10] Add function to get number of PT_LOAD for cyclic processing Atsushi Kumagai
2012-06-29  2:23 ` [RFC PATCH v2 8/10] Implement the main routine of cyclic processing for ELF format Atsushi Kumagai
2012-06-29  2:24 ` [RFC PATCH v2 9/10] Enabling --split option with cyclic processing Atsushi Kumagai
2012-06-29  2:25 ` [RFC PATCH v2 10/10] Change num_dumped value to global for debug messages Atsushi Kumagai
2012-07-02 12:39 ` [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption Vivek Goyal
2012-07-04  5:54   ` Atsushi Kumagai
2012-07-04  8:52     ` HATAYAMA Daisuke
2012-07-11  5:23       ` HATAYAMA Daisuke
2012-07-13  0:36         ` Atsushi Kumagai
2012-07-13  5:18           ` HATAYAMA Daisuke
2012-07-13  8:10             ` Atsushi Kumagai
2012-07-18  0:57               ` HATAYAMA Daisuke
2012-08-06 20:47 ` Vivek Goyal
2012-08-07  7:31   ` HATAYAMA Daisuke
2012-08-10  8:39     ` HATAYAMA Daisuke
2012-08-10 14:36       ` Vivek Goyal
2012-08-14 11:55         ` HATAYAMA Daisuke
2012-08-15  6:27           ` Atsushi Kumagai
2012-08-15 13:31             ` Vivek Goyal [this message]
2012-08-20  0:12             ` HATAYAMA Daisuke
2012-08-29  2:50             ` HATAYAMA Daisuke
2012-08-29 12:35               ` Vivek Goyal
2012-08-30  0:55                 ` HATAYAMA Daisuke
2012-08-30  6:29                   ` Atsushi Kumagai
2012-08-08  5:14   ` Atsushi Kumagai
2012-08-08 13:25     ` Vivek Goyal
2012-08-09  6:44       ` 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=20120815133102.GA17033@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=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.