The patch titled
Align the node_mem_map endpoints to a MAX_ORDER boundary
has been added to the -mm tree. Its filename is
align-the-node_mem_map-endpoints-to-a-max_order-boundary.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: Align the node_mem_map endpoints to a MAX_ORDER boundary
From: Bob Picco <bob.picco@xxxxxx>
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@xxxxxx>
Acked-by: Mel Gorman <mel@xxxxxxxxx>
Cc: Dave Hansen <haveblue@xxxxxxxxxx>
Cc: Andy Whitcroft <apw@xxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
include/linux/mmzone.h | 1 +
mm/page_alloc.c | 14 +++++++++++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff -puN include/linux/mmzone.h~align-the-node_mem_map-endpoints-to-a-max_order-boundary include/linux/mmzone.h
--- 25/include/linux/mmzone.h~align-the-node_mem_map-endpoints-to-a-max_order-boundary Fri May 19 13:50:11 2006
+++ 25-akpm/include/linux/mmzone.h Fri May 19 13:50:11 2006
@@ -21,6 +21,7 @@
#else
#define MAX_ORDER CONFIG_FORCE_MAX_ZONEORDER
#endif
+#define MAX_ORDER_NR_PAGES (1 << (MAX_ORDER - 1))
struct free_area {
struct list_head free_list;
diff -puN mm/page_alloc.c~align-the-node_mem_map-endpoints-to-a-max_order-boundary mm/page_alloc.c
--- 25/mm/page_alloc.c~align-the-node_mem_map-endpoints-to-a-max_order-boundary Fri May 19 13:50:11 2006
+++ 25-akpm/mm/page_alloc.c Fri May 19 13:50:11 2006
@@ -2206,14 +2206,22 @@ static void __init alloc_node_mem_map(st
#ifdef CONFIG_FLAT_NODE_MEM_MAP
/* ia64 gets its own node_mem_map, before this, without bootmem */
if (!pgdat->node_mem_map) {
- unsigned long size;
+ unsigned long size, start, end;
struct page *map;
- size = (pgdat->node_spanned_pages + 1) * sizeof(struct page);
+ /*
+ * The zone's endpoints aren't required to be MAX_ORDER
+ * aligned but the node_mem_map endpoints must be in order
+ * for the buddy allocator to function correctly.
+ */
+ start = pgdat->node_start_pfn & ~(MAX_ORDER_NR_PAGES - 1);
+ end = pgdat->node_start_pfn + pgdat->node_spanned_pages;
+ end = ALIGN(end, MAX_ORDER_NR_PAGES);
+ size = (end - start) * sizeof(struct page);
map = alloc_remap(pgdat->node_id, size);
if (!map)
map = alloc_bootmem_node(pgdat, size);
- pgdat->node_mem_map = map;
+ pgdat->node_mem_map = map + (pgdat->node_start_pfn - start);
}
#ifdef CONFIG_FLATMEM
/*
_
Patches currently in -mm which might be from bob.picco@xxxxxx are
align-the-node_mem_map-endpoints-to-a-max_order-boundary.patch
introduce-mechanism-for-registering-active-regions-of-memory.patch
have-power-use-add_active_range-and-free_area_init_nodes.patch
have-x86-use-add_active_range-and-free_area_init_nodes.patch
have-x86_64-use-add_active_range-and-free_area_init_nodes.patch
have-ia64-use-add_active_range-and-free_area_init_nodes.patch
sparsemem-record-nid-during-memory-present.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
