[PATCH v2 08/10] Add page_is_buddy for PG_buddy

[Hatayama, Daisuke]

> From: kexec-bounces at lists.infradead.org
> [mailto:kexec-bounces at lists.infradead.org] On Behalf Of Atsushi Kumagai
> Sent: Tuesday, November 27, 2012 3:01 PM
> Subject: Re: [PATCH v2 08/10] Add page_is_buddy for PG_buddy
> 
> Hello HATAYAMA-san,
> 
> On Fri, 16 Nov 2012 14:02:13 +0900
> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:
> 
> > On kernels from v2.6.18 to v2.6.37, buddy page is marked by the
> > PG_buddy flag.
> >
> >   kernel version     | PG_buddy
> >   ------------------ +---------------------------------
> >   v2.6.17 to v2.6.26 | 19
> >   v2.6.27 to v2.6.37 | 19 if CONFIG_PAGEFLAGS_EXTEND=y
> >                      | 18 otherwise
> >
> > We don't need to care about CONFIG_PAGEFLAGS_EXTEND because the
> > architectures specifying this as y are um and xtensa only. They are
> > not included in the supported architectures of makedumpfile.
> 
> Sorry for too late point out.
> 
> I did regression test for v1.5.1 on x86_64 machine in the last weekend
> and found the issue that page_is_buddy_v2() can't exclude free pages
> correctly for kernel 2.6.30 to 2.6.37.
> I checked the configuration of these kernels, I made sure that
> CONFIG_PAGEFLAGS_EXTENDED was set as y, so PG_buddy=18 is invalid for them.
> 
> According to this fact, PG_buddy is variable for the supported architectures
> of makedumpfile, too.
> So, how did you confirm that CONFIG_PAGEFLAGS_EXTENDED is only related with
> um and xtensa ?
> 

I guess I used git grep on different kernel source tree.

> And why did you test with PG_buddy=19 for 2.6.32 when you posted this patch
> set?
> 
> >  - 2.6.32
> >  NUMBER(PG_slab)=7
> >  NUMBER(PG_buddy)=19
> >  OFFSET(page._mapcount)=12
> >  OFFSET(page.private)=16
> >  SIZE(pageflags)=4
> 

Sorry, I was not aware of this.

Anyway, the current hard-coded values doesn't work at all since before talking
about PG_buddy, we cannot get values of page structure's members, such as offset
value of private member, so non-cyclic is always used instead.

How about dropping hard-coded values?

Thanks.
HATAYAMA, Daisuke