On Thu, Nov 18, 2010 at 04:08:01PM +0000, Mel Gorman wrote: > On Wed, Nov 03, 2010 at 04:28:20PM +0100, Andrea Arcangeli wrote: > > From: Andrea Arcangeli <aarcange@xxxxxxxxxx> > > > > 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. > > > > Does this make much of a difference? I confess I didn't read the patch closely > because I didn't get the motivation. The motivation is described in the first line. If I wouldn't remove PG_buddy, introducing PG_compound_lock would overflow the 32bit build with CONFIG_X86_PAE=y and CONFIG_X86_PAT=y. The bitflag easier to nuke was PG_buddy. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>