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: kexec@lists.infradead.org
Subject: Re: [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption.
Date: Mon, 2 Jul 2012 08:39:05 -0400	[thread overview]
Message-ID: <20120702123905.GG24929@redhat.com> (raw)
In-Reply-To: <20120629111320.694ec85b.kumagai-atsushi@mxc.nes.nec.co.jp>

On Fri, Jun 29, 2012 at 11:13:20AM +0900, Atsushi Kumagai wrote:
> Hello,
> 
> I improved prototype of cyclic processing as version 2.
> If there is no objection to basic idea, I want to consider the things
> related to performance as next step. (Concretely, buffer size and the patch set
> HATAYAMA-san sent a short time ago.) 
> 

Hi Atushi san,

Good to see this work making progress. I have few queries.

- Do you have some numbers for bigger machines like 1TB or higher memory. 
  I am curious to know how bad is the time penalty.

- Will this work with option -F (flattned format). Often people save
  filtered dump over ssh and we need to make sure it does work with -F
  option too.

> > Version 1:
>  
>   http://lists.infradead.org/pipermail/kexec/2012-May/006363.html

- I have few queries about the diagram in the link above.

- What is 1st cycle, 2nd cycle and 3rd cycle. Are we cycling thorough
  all the pages 3 times for everything?

- What is 1st bitmap and 2nd bitmap and page_header? And why 3 cycles for
  each.

- And why 3 cycles for page_data.

Thanks
Vivek

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

  parent reply	other threads:[~2012-07-02 12:39 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 ` Vivek Goyal [this message]
2012-07-04  5:54   ` [RFC PATCH v2 0/10] makedumpfile: cyclic processing to keep memory consumption 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
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=20120702123905.GG24929@redhat.com \
    --to=vgoyal@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.