All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: akpm@osdl.org
Cc: Mel Gorman <mel@csn.ul.ie>,
	nickpiggin@yahoo.com.au, haveblue@us.ibm.com, ak@suse.de,
	bob.picco@hp.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, apw@shadowen.org, mingo@elte.hu,
	mbligh@mbligh.org
Subject: [PATCH 1/2] Align the node_mem_map endpoints to a MAX_ORDER boundary
Date: Fri, 19 May 2006 14:43:01 +0100 (IST)	[thread overview]
Message-ID: <20060519134301.29021.71137.sendpatchset@skynet> (raw)
In-Reply-To: <20060519134241.29021.84756.sendpatchset@skynet>


From: Bob Picco <bob.picco@hp.com>

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.


 include/linux/mmzone.h |    1 +
 mm/page_alloc.c        |   14 +++++++++++---
 2 files changed, 12 insertions(+), 3 deletions(-)

Signed-off-by: Bob Picco <bob.picco@hp.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>

diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc4-mm1-clean/include/linux/mmzone.h linux-2.6.17-rc4-mm1-101-bob-node-alignment/include/linux/mmzone.h
--- linux-2.6.17-rc4-mm1-clean/include/linux/mmzone.h	2006-05-18 17:23:55.000000000 +0100
+++ linux-2.6.17-rc4-mm1-101-bob-node-alignment/include/linux/mmzone.h	2006-05-18 17:52:13.000000000 +0100
@@ -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 -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc4-mm1-clean/mm/page_alloc.c linux-2.6.17-rc4-mm1-101-bob-node-alignment/mm/page_alloc.c
--- linux-2.6.17-rc4-mm1-clean/mm/page_alloc.c	2006-05-18 17:23:55.000000000 +0100
+++ linux-2.6.17-rc4-mm1-101-bob-node-alignment/mm/page_alloc.c	2006-05-18 17:58:10.000000000 +0100
@@ -2484,14 +2484,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
 	/*

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: akpm@osdl.org
Cc: Mel Gorman <mel@csn.ul.ie>,
	nickpiggin@yahoo.com.au, haveblue@us.ibm.com, ak@suse.de,
	bob.picco@hp.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, apw@shadowen.org, mingo@elte.hu,
	mbligh@mbligh.org
Subject: [PATCH 1/2] Align the node_mem_map endpoints to a MAX_ORDER boundary
Date: Fri, 19 May 2006 14:43:01 +0100 (IST)	[thread overview]
Message-ID: <20060519134301.29021.71137.sendpatchset@skynet> (raw)
In-Reply-To: <20060519134241.29021.84756.sendpatchset@skynet>

From: Bob Picco <bob.picco@hp.com>

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.


 include/linux/mmzone.h |    1 +
 mm/page_alloc.c        |   14 +++++++++++---
 2 files changed, 12 insertions(+), 3 deletions(-)

Signed-off-by: Bob Picco <bob.picco@hp.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>

diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc4-mm1-clean/include/linux/mmzone.h linux-2.6.17-rc4-mm1-101-bob-node-alignment/include/linux/mmzone.h
--- linux-2.6.17-rc4-mm1-clean/include/linux/mmzone.h	2006-05-18 17:23:55.000000000 +0100
+++ linux-2.6.17-rc4-mm1-101-bob-node-alignment/include/linux/mmzone.h	2006-05-18 17:52:13.000000000 +0100
@@ -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 -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc4-mm1-clean/mm/page_alloc.c linux-2.6.17-rc4-mm1-101-bob-node-alignment/mm/page_alloc.c
--- linux-2.6.17-rc4-mm1-clean/mm/page_alloc.c	2006-05-18 17:23:55.000000000 +0100
+++ linux-2.6.17-rc4-mm1-101-bob-node-alignment/mm/page_alloc.c	2006-05-18 17:58:10.000000000 +0100
@@ -2484,14 +2484,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
 	/*

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-05-19 13:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19 13:42 [PATCH 0/2] Fixes for node alignment and flatmem assumptions Mel Gorman
2006-05-19 13:42 ` Mel Gorman
2006-05-19 13:43 ` Mel Gorman [this message]
2006-05-19 13:43   ` [PATCH 1/2] Align the node_mem_map endpoints to a MAX_ORDER boundary Mel Gorman
2006-05-19 20:49   ` Andrew Morton
2006-05-19 20:49     ` Andrew Morton
2006-05-19 23:25     ` Mel Gorman
2006-05-19 23:25       ` Mel Gorman
2006-05-22  8:25     ` Andy Whitcroft
2006-05-22  8:25       ` Andy Whitcroft
2006-05-22  8:44       ` Andrew Morton
2006-05-22  8:44         ` Andrew Morton
2006-05-19 13:43 ` [PATCH 2/2] FLATMEM relax requirement for memory to start at pfn 0 Mel Gorman
2006-05-19 13:43   ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060519134301.29021.71137.sendpatchset@skynet \
    --to=mel@csn.ul.ie \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=apw@shadowen.org \
    --cc=bob.picco@hp.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@mbligh.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.