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: Wed, 8 Aug 2012 09:25:10 -0400	[thread overview]
Message-ID: <20120808132510.GB15623@redhat.com> (raw)
In-Reply-To: <20120808141400.d4c65848973b62e191573795@mxc.nes.nec.co.jp>

On Wed, Aug 08, 2012 at 02:14:00PM +0900, Atsushi Kumagai wrote:
> Hello Vivek,
> 
> On Mon, 6 Aug 2012 16:47:31 -0400
> Vivek Goyal <vgoyal@redhat.com> wrote:
> 
> > 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 Atsushi San,
> > 
> > Just checking that what's the state of these patches now. Are they ready
> > to be included in makedumpfile?
> 
> Yes, v2 patches with some fixes are ready to be merged into mainline.
> At this time, makedumpfile can work in constant memory space.
> (To make sure it's correct, we need to see the result of HATAYAMA-san's benchmark.)
> 
> > I would love to see new makedumpfile where memory usage does not grow
> > by physical memory present in the system. (Assuming computig overhead
> > of cycles is bearable).
> 
> I planed to release the next version with the new method to exclude free pages
> (based on HATAYAMA-san's RFC patches). This method looks up members of each page
> instead of free_list, it's only for performance.
> 
>   http://lists.infradead.org/pipermail/kexec/2012-June/006441.html
> 
> But, this method need more time for consideration, review and test.
> 
> 
> If you need the new makedumpfile which can work in constant memory space soon,
> shall I release the new version as soon as possible ? 
> (But, this version still looks up free_list to exclude free pages same as v1.4.4.)
> 

I think once Hatayama's testing is done, it is a good idea to merge cyclic
patches and make a release. And soon after review and testing, merge
hatayama's other patches of walking through mem_map array. My understanding
is that walking through mem_map array will save us cpu cycles in fixed
memory usage mode.

Thanks
Vivek

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

  reply	other threads:[~2012-08-08 13:25 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
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 [this message]
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=20120808132510.GB15623@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.