From: Arthur Zou <zzou@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: d hatayama <d.hatayama@jp.fujitsu.com>,
kexec@lists.infradead.org, vgoyal@redhat.com
Subject: Re: makedumpfile memmory usage seems high with option -E
Date: Fri, 11 Apr 2014 06:19:38 -0400 (EDT) [thread overview]
Message-ID: <585335973.3025244.1397211578378.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE97201A0F@BPXM01GP.gisp.nec.co.jp>
----- Original Message -----
> Hello Vivek,
>
> >Hi Atsushi/Hatayama,
> >
> >We noticed in our testing that makedumpfile gets OOM killed if we happen
> >to use -E option. Saving to compressed kdump format works just fine.
> >
> >Also we noticed that with -E if we disable cyclic mode then it works just
> >fine.
> >
> >So looks like something is going on with -E and cyclic mode enabled. I am
> >not sure what it is.
> >
> >Do you suspect something?
>
> At first, I supposed the function to calculate cyclic buffer size may
> be related to this issue, but I haven't found the answer yet...
>
> int
> calculate_cyclic_buffer_size() {
>
> if (info->flag_elf_dumpfile) {
> free_size = get_free_memory_size() * 0.4;
> needed_size = (info->max_mapnr * 2) / BITPERBYTE;
> } else {
> free_size = get_free_memory_size() * 0.8;
> needed_size = info->max_mapnr / BITPERBYTE;
> }
> [...]
> info->bufsize_cyclic = (free_size <= needed_size) ? free_size :
> needed_size;
>
>
> I've found this function has an issue about memory allocation.
> When -E is specified, info->bufsize_cyclic will be the total size of
> the 1st and 2nd bitmap if free memory is enough. Then,
> info->bufsize_cyclic will be used to allocate each bitmap in
> prepare_bitmap_buffer_cyclic() like below:
>
> if ((info->partial_bitmap1 = (char *)malloc(info->bufsize_cyclic)) ==
> NULL) {
> ERRMSG("Can't allocate memory for the 1st-bitmap. %s\n",
> strerror(errno));
> return FALSE;
> }
> if ((info->partial_bitmap2 = (char *)malloc(info->bufsize_cyclic)) ==
> NULL) {
> ERRMSG("Can't allocate memory for the 2nd-bitmap. %s\n",
> strerror(errno));
> return FALSE;
> }
>
> It's a too much allocation definitely, but it mustn't exceed 80% of free
> memory due to the condition check in calculate_cyclic_buffer_size(), so
> I think the OOM issue will not happen by this issue.
> I'll fix this too much allocation with the patch below, but it will not
> resolve your OOM issue...
>
> BTW, what are your version of makedumpfile and crashkernel= size and
> the system memory size? and does the issue happen even if you specify
> --cyclic-buffer which is small enough to fit the available memory ?
> I'm curious to know the details of the condition which cause the issue.
>
>
Hi Atsushi Kumagai
The makedumpfile version is 1.5.4. crashkernel=auto which actually is 166M.
the system memory size is about 96G and the arch is x86_64 which kernel version
3.10.110. But the same issue happened when using the newest makedumpfile in devel
branch. After add --cyclic-buffer=100, dump succeed.
Thanks
arthur
> Thanks
> Atsushi Kumagai
>
>
> diff --git a/makedumpfile.c b/makedumpfile.c
> index 75092a8..ae9e69a 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -8996,7 +8996,7 @@ out:
> */
> int
> calculate_cyclic_buffer_size(void) {
> - unsigned long long free_size, needed_size;
> + unsigned long long limit_size, bitmap_size;
>
> if (info->max_mapnr <= 0) {
> ERRMSG("Invalid max_mapnr(%llu).\n", info->max_mapnr);
> @@ -9009,18 +9009,17 @@ calculate_cyclic_buffer_size(void) {
> * within 80% of free memory.
> */
> if (info->flag_elf_dumpfile) {
> - free_size = get_free_memory_size() * 0.4;
> - needed_size = (info->max_mapnr * 2) / BITPERBYTE;
> + limit_size = get_free_memory_size() * 0.4;
> } else {
> - free_size = get_free_memory_size() * 0.8;
> - needed_size = info->max_mapnr / BITPERBYTE;
> + limit_size = get_free_memory_size() * 0.8;
> }
> + bitmap_size = info->max_mapnr / BITPERBYTE;
>
> /* if --split was specified cyclic buffer allocated per dump file */
> if (info->num_dumpfile > 1)
> - needed_size /= info->num_dumpfile;
> + bitmap_size /= info->num_dumpfile;
>
> - info->bufsize_cyclic = (free_size <= needed_size) ? free_size :
> needed_size;
> + info->bufsize_cyclic = (limit_size <= bitmap_size) ? limit_size :
> bitmap_size;
>
> return TRUE;
> }
> --
> 1.8.0.2
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-04-11 10:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 21:44 makedumpfile memmory usage seems high with option -E Vivek Goyal
2014-04-11 9:22 ` Atsushi Kumagai
2014-04-11 10:19 ` Arthur Zou [this message]
2014-04-14 8:02 ` [PATCH] makedumpfile: change the wrong code to calculate bufsize_cyclic for elf dump Baoquan He
2014-04-14 8:11 ` Baoquan He
2014-04-16 6:44 ` Baoquan He
2014-04-17 4:01 ` Atsushi Kumagai
2014-04-17 4:52 ` bhe
2014-04-17 5:02 ` bhe
2014-04-18 9:22 ` Atsushi Kumagai
2014-04-18 14:29 ` bhe
2014-04-18 19:41 ` Petr Tesarik
2014-04-21 15:19 ` Vivek Goyal
2014-04-21 15:46 ` Petr Tesarik
2014-04-21 15:51 ` Vivek Goyal
2014-04-21 15:14 ` Vivek Goyal
2014-04-23 11:09 ` bhe
2014-04-21 15:12 ` Vivek Goyal
2014-04-23 7:55 ` Atsushi Kumagai
2014-04-23 11:55 ` bhe
2014-04-23 17:08 ` Vivek Goyal
2014-04-23 23:50 ` bhe
2014-04-24 2:05 ` bhe
2014-04-25 13:22 ` Vivek Goyal
2014-04-28 5:05 ` Atsushi Kumagai
2014-04-28 12:50 ` Vivek Goyal
2014-05-09 5:36 ` Atsushi Kumagai
2014-05-09 20:49 ` Vivek Goyal
2014-05-15 7:22 ` bhe
2014-05-15 9:10 ` Atsushi Kumagai
2014-05-19 11:15 ` bhe
2014-05-19 15:11 ` Vivek Goyal
2014-05-27 5:34 ` Atsushi Kumagai
2014-05-27 14:49 ` Vivek Goyal
2014-05-23 7:18 ` Atsushi Kumagai
2014-05-14 5:44 ` bhe
2014-04-28 5:04 ` Atsushi Kumagai
2014-05-09 5:35 ` 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=585335973.3025244.1397211578378.JavaMail.zimbra@redhat.com \
--to=zzou@redhat.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=vgoyal@redhat.com \
/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.