Hello HATAYAMA-san, 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.) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41065 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. Thanks Atsushi Kumagai
