]> err.no Git - linux-2.6/commit
[PATCH] Align the node_mem_map endpoints to a MAX_ORDER boundary
authorBob Picco <bob.picco@hp.com>
Sat, 20 May 2006 22:00:31 +0000 (15:00 -0700)
committerLinus Torvalds <torvalds@g5.osdl.org>
Sun, 21 May 2006 19:59:22 +0000 (12:59 -0700)
commite984bb43f7450312ba66fe0e67a99efa6be3b246
tree54c86240172136fc81c773f71cd70eda54fed6f2
parentae57a856429dd932c547530df1b234eb7e642297
[PATCH] Align the node_mem_map endpoints to a MAX_ORDER boundary

Andy added code to buddy allocator which does not require the zone's
endpoints to be aligned to MAX_ORDER.  An issue is that the buddy allocator
requires the node_mem_map's endpoints to be MAX_ORDER aligned.  Otherwise
__page_find_buddy could compute a buddy not in node_mem_map for partial
MAX_ORDER regions at zone's endpoints.  page_is_buddy will detect that
these pages at endpoints are not PG_buddy (they were zeroed out by bootmem
allocator and not part of zone).  Of course the negative here is we could
waste a little memory but the positive is eliminating all the old checks
for zone boundary conditions.

SPARSEMEM won't encounter this issue because of MAX_ORDER size constraint
when SPARSEMEM is configured.  ia64 VIRTUAL_MEM_MAP doesn't need the logic
either because the holes and endpoints are handled differently.  This
leaves checking alloc_remap and other arches which privately allocate for
node_mem_map.

Signed-off-by: Bob Picco <bob.picco@hp.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
include/linux/mmzone.h
mm/page_alloc.c