makedumpfile memory usage grows with system memory size

[HATAYAMA Daisuke]

From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
Subject: Re: makedumpfile memory usage grows with system memory size
Date: Fri, 6 Apr 2012 17:59:24 +0900

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

I agree. On the other hand, there is one more thing to consider. The
value of order is in private member of the page descripter. Now
there's no information for private member in VMCOREINFO. If we choose
this method and delete the current one, it's necessary to prepare
vmlinux file for old kernels.

Thanks.
HATAYAMA, Daisuke