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: Fri, 10 Aug 2012 10:36:55 -0400	[thread overview]
Message-ID: <20120810143655.GA5416@redhat.com> (raw)
In-Reply-To: <20120810.173938.37160718.d.hatayama@jp.fujitsu.com>

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.
> 

Thanks a lot for doing this benchmarking.

> The machine spec I used is as follows:
> 
>   Memory: 2TB
>   CPU: Intel(R) Xeon(R) CPU E7- 8870  @ 2.40GHz
>        (8 sockets, 10 cores, 2 threads)
> 
> In the first step, I chosed buffer size 10KB and it took about 3h 45m
> 57s. So, next I changed the buffer size to 512KB and measured up to
> 8MB.

What is this buffer size? Is user supposed to specify it? Is it some fixed
size buffer which makedumpfile can use to read in memory and once we cross
the buffer size we need to let some data from buffer go?

> 
> The result is as follows:
> 
> | buffer size | time       |
> |-------------+------------|
> | 8 MB        | 48.32 sec  |
> | 4 MB        | 55.76 sec  |
> | 2 MB        | 69.91 sec  |
> | 1 MB        | 98.25 sec  |
> | 512 KB      | 154.42 sec |

So, on a 2TB system, with 8MB buffer, we could filter and save vmcore in
around 48 seconds? Or is it just filtering time.

48 seconds for 2TB system, sounds pretty decent to me.

Are these results with existing free_list implementation or with your
patches of walking through mem_map array?

> 
> BTW, the existing free_list logic took about 48 sec for the same
> vmcore as below.

I guess above results were with your patches of walking mem_map array.

> 
> 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.

Does that mean that filtering time for both mem_map array approach and
free_list approach are same?

Thanks
Vivek

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

  reply	other threads:[~2012-08-10 14:37 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 [this message]
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=20120810143655.GA5416@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.