Re: makedumpfile memory usage grows with system memory size

Atsushi Kumagai
2012-04-06T09:00:44Z

Hello Hatayama-san,

On Fri, 06 Apr 2012 10:12:12 +0900 ( )
HATAYAMA Daisuke <d.hatayama@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@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@redhat.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@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