[PATCH v2 08/10] Add page_is_buddy for PG_buddy
kumagai-atsushi at mxc.nes.nec.co.jp
Wed Nov 28 02:42:31 EST 2012
On Tue, 27 Nov 2012 08:53:00 +0000
"Hatayama, Daisuke" <d.hatayama at jp.fujitsu.com> wrote:
> > 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.
OK, I see.
> 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?
It seems better to drop hard-coded values.
vmlinux (or vmcoreinfo) is necessary to get values of page structure's
members and we can get NUMBER(PG_buddy) from vmlinux as well.
So, I think the hard-coding for PG_buddy brings few benefits.
I misunderstood that enumeration values can't be gotten from vmlinux,
so I thought the hard-coding is reasonable.
(I seem to just faced the gcc bug below.)
Anyway, to sum it up:
1. If vmlinux or vmcoreinfo is prepared and running on cyclic mode,
page_is_buddy_v2() works correctly for v2.6.18 to v2.6.37.
2. Otherwise, free list logic is used.
I think it's good policy for current kernels.
More information about the kexec