From: Vivek Goyal <vgoyal@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "d.hatayama@jp.fujitsu.com" <d.hatayama@jp.fujitsu.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"zzou@redhat.com" <zzou@redhat.com>,
"bhe@redhat.com" <bhe@redhat.com>
Subject: Re: [PATCH] makedumpfile: change the wrong code to calculate bufsize_cyclic for elf dump
Date: Fri, 9 May 2014 16:49:24 -0400 [thread overview]
Message-ID: <20140509204924.GA9918@redhat.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9720F928@BPXM01GP.gisp.nec.co.jp>
On Fri, May 09, 2014 at 05:36:13AM +0000, Atsushi Kumagai wrote:
[..]
> I tried to reproduce OOM in my environment.
> Unfortunately, I couldn't get a chance to use a large memory machine,
> so I controlled the bitmap buffer size with --cyclic-buffer like below:
>
> / # free
> total used free shared buffers
> Mem: 37544 19796 17748 0 56
> Swap: 0 0 0
> Total: 37544 19796 17748
> / # /mnt/usr/sbin/makedumpfile_static -E --cyclic-buffer=8000 /proc/vmcore /mnt/tmp/dumpfile.E
> Copying data : [100.0 %] |
>
> The dumpfile is saved to /mnt/tmp/dumpfile.E.
>
> makedumpfile Completed.
> VmHWM: 16456 kB
> / #
>
> As above, OOM didn't happen even when makedumpfile consumed most of the
> available memory (the remains were only 1MB).
>
> Of course, OOM happened when the memory usage exceeded the limit:
Hi Atsushi,
I think this is the key point. How did makedumpfile exceed the limit. So
if you don't specify --cyclic-buffer=X, then makedumpfile will allocate
80% of available memory. That would be roughly 16MB of cyclic buffer
(instead of 8MB).
In your test case looks like makeudmpfile used 16MB of memory. Out of
which 8MB must have been used for bitmaps and rest 8MB for other purposes.
So clearly our calculation of using 80% of available memory for bitmaps
is not right. Rest of the 20% memory might not be enough for fulfilling
the needs of makeudmpfile.
We don't have a good way to determine how much *non-bitmap* memory
allocation makedumpfile requires. I am wondering how about making
some assumtions and modify the formula for bitmap memory.
- Assume makedumpfile requires 16MB of free memory for various purposes.
- Subtract 16MB from available memory and take 80% of remaining memory
to calculate the bitmap memory size.
- Keep 4MB as minimum for bitmap buffer size.
One more person has reported makedumpfile OOM (even without -E option),
on a machine. There also 30MB of memory is free. I think it has the
same issue that 24MB must have been allocated in bitmaps and remainig
6MB is not sufficient to satisfy makedumpfile's needs.
What do you think?
Also, does anybody know what's the impact of bitmap buffer size on dump
speed. Does dump speed change significantly with bitmap buffer size?
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-05-09 20:49 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
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 [this message]
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=20140509204924.GA9918@redhat.com \
--to=vgoyal@redhat.com \
--cc=bhe@redhat.com \
--cc=d.hatayama@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=zzou@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).