makedumpfile memory usage grows with system memory size
kumagai-atsushi at mxc.nes.nec.co.jp
Fri Apr 6 04:59:24 EDT 2012
On Fri, 06 Apr 2012 10:12:12 +0900 ( )
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
> Thanks. To be honest, I have just beginning with reading around here
> and known PG_buddy just now. I have small checked this fact on 2.6.18
> with the patch in the bottom of this mail and free pages found from
> free_list and by PG_buddy check are coincide.
> As Vivek says, more recent kernel has change around PG_buddy and the
> patch says we should check _mapcount; I have yet to check this.
> Author: Andrea Arcangeli <aarcange at redhat.com>
> Date: Thu Jan 13 15:47:00 2011 -0800
> thp: remove PG_buddy
> PG_buddy can be converted to _mapcount == -2. So the PG_compound_lock can
> be added to page->flags without overflowing (because of the sparse section
> bits increasing) with CONFIG_X86_PAE=y and CONFIG_X86_PAT=y. This also
> has to move the memory hotplug code from _mapcount to lru.next to avoid
> any risk of clashes. We can't use lru.next for PG_buddy removal, but
> memory hotplug can use lru.next even more easily than the mapcount
> Signed-off-by: Andrea Arcangeli <aarcange at redhat.com>
> Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
> $ git describe 5f24ce5fd34c3ca1b3d10d30da754732da64d5c0
> So now we can walk on the memmap array also for free pages like other
> kinds of memory. The question I have now is why the current
> implementation was chosen. Is there any difference between two ways?
We just referred to the implementation of disk_dump.
Now, I'm checking the validity of using _count field to figure out free pages.
I would like to use _count rather than PG_buddy because I would like to avoid
changing behavior based on versions as long as possible.
More information about the kexec