hugetlbfs: handle pages higher order than MAX_ORDER
authorAndy Whitcroft <apw@shadowen.org>
Fri, 7 Nov 2008 00:06:24 +0000 (00:06 +0000)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 13 Nov 2008 17:55:56 +0000 (09:55 -0800)
commit70e6b95d14d2f7f5202be36a808e7085a0f4ea96
treeb5dceb1d544d9403c597756ce7c6b4441d7f21a3
parent75187a3094a68015582b344161c18b86ab60e665
hugetlbfs: handle pages higher order than MAX_ORDER

commit 69d177c2fc702d402b17fdca2190d5a7e3ca55c5 upstream

When working with hugepages, hugetlbfs assumes that those hugepages are
smaller than MAX_ORDER.  Specifically it assumes that the mem_map is
contigious and uses that to optimise access to the elements of the mem_map
that represent the hugepage.  Gigantic pages (such as 16GB pages on
powerpc) by definition are of greater order than MAX_ORDER (larger than
MAX_ORDER_NR_PAGES in size).  This means that we can no longer make use of
the buddy alloctor guarentees for the contiguity of the mem_map, which
ensures that the mem_map is at least contigious for maximmally aligned
areas of MAX_ORDER_NR_PAGES pages.

This patch adds new mem_map accessors and iterator helpers which handle
any discontiguity at MAX_ORDER_NR_PAGES boundaries.  It then uses these to
implement gigantic page versions of copy_huge_page and clear_huge_page,
and to allow follow_hugetlb_page handle gigantic pages.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Cc: Jon Tollefson <kniht@linux.vnet.ibm.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/hugetlb.c
mm/internal.h