makedumpfile memory usage grows with system memory size

[Atsushi Kumagai]

Hello Hatayama-san,

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
>     instead.
> 
>     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
> v2.6.37-7012-g5f24ce5
> 
> 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.


Thanks
Atsushi Kumagai