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: kexec@lists.infradead.org, kumagai-atsushi@mxc.nes.nec.co.jp
Subject: Re: [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption.
Date: Wed, 29 Aug 2012 08:35:39 -0400	[thread overview]
Message-ID: <20120829123539.GA12504@redhat.com> (raw)
In-Reply-To: <20120829.115031.346071170.d.hatayama@jp.fujitsu.com>

On Wed, Aug 29, 2012 at 11:50:31AM +0900, HATAYAMA Daisuke wrote:
> From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
> Subject: Re: [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption.
> Date: Wed, 15 Aug 2012 15:27:10 +0900
> 
> > Hello HATAYAMA-san,
> > 
> > On Tue, 14 Aug 2012 20:55:32 +0900 (JST)
> > HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> > 
> >> From: Vivek Goyal <vgoyal@redhat.com>
> >> Subject: Re: [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption.
> >> Date: Fri, 10 Aug 2012 10:36:55 -0400
> >> 
> >> > On Fri, Aug 10, 2012 at 05:39:38PM +0900, HATAYAMA Daisuke wrote:
> >> > 
> >> > [..]
> >> >> 
> >> >> I finished benchmarking filtering time and demonstrate the result.
> >> >> But I failed to collect amount of memory consumption by my mistake. If
> >> >> they are necessary, I'll again try to collect them. But we have 9 days
> >> >> vacation starting tommorow, so I'll do that after the vacation.
> >> >> 
> > 
> > Thank you for your help.
> > Could you continue to measure amount of memory consumption ?
> > 
> 
> Hello Kumagai-san, here is the benchmark result for the amount of
> actual memory consumption when there are multiple child processes
> using --split option.
> 

Hi,

Thanks for testing results. I had few questions.

- What's the objective of this testing? Are we just trying to figure out
  memory footprint of makedumpfile in cyclic mode using struct page 
  filtering and compare with free list filtering?

- Why are we testing using --split option. How does that help. In kdump
  kernel we boot only 1 cpu. And if all the dump files are being saved
  to same disk, it might not give lot of performance boost.
 
  Even if does give performance boost, this seems to be orthogonal to 
  the idea of going using struct page for filtering.  Will single thread
  dumping not give a good idea about memory footprint?


- What's the conclusion of below measurements and numbers.

Thanks
Vivek

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

  reply	other threads:[~2012-08-29 12:35 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
2012-08-20  0:12             ` HATAYAMA Daisuke
2012-08-29  2:50             ` HATAYAMA Daisuke
2012-08-29 12:35               ` Vivek Goyal [this message]
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=20120829123539.GA12504@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.