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
