From: Dave Hansen <haveblue@us.ibm.com>
To: Bob Picco <bob.picco@hp.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
"Martin J. Bligh" <mbligh@mbligh.org>, Andi Kleen <ak@suse.de>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
Linux Memory Management <linux-mm@kvack.org>,
Andy Whitcroft <apw@shadowen.org>
Subject: Re: assert/crash in __rmqueue() when enabling CONFIG_NUMA
Date: Thu, 04 May 2006 08:21:06 -0700 [thread overview]
Message-ID: <1146756066.22503.17.camel@localhost.localdomain> (raw)
In-Reply-To: <20060504013239.GG19859@localhost>
I haven't thought through it completely, but these two lines worry me:
> + start = pgdat->node_start_pfn & ~((1 << (MAX_ORDER - 1)) - 1);
> + end = start + pgdat->node_spanned_pages;
Should the "end" be based off of the original "start", or the aligned
"start"?
(using decimal math to make it easy) ...
Let's say that MAX_ORDER comes out to be 10 pages. node_start_pfn is 9,
and the node's end pfn is 21. node_spanned_pages will be 12. "start"
will get rounded down to 0. "end" will be "start" (0) +
node_spanned_pages (12), so 12. "end" then gets rounded up to 20.
However, this is not sufficient space for the mem_map as the node
*actually* ended at 21.
I think that "end" needs to be calculated without rounding down the
start_pfn, or the node_spanned_pages number needs to be rounded up in
the same way that "end" is.
Does that sound right?
Also, it might look nicer if there was an intermediate variable
something like this:
#define MAX_ORDER_NR_PAGES (1 << (MAX_ORDER - 1))
Take a look at the loop below, I've also used ALIGN() from kernel.h for
the "end" alignment. I think it is just a drop-in replacement.
/* ia64 gets its own node_mem_map, before this, without bootmem */
if (!pgdat->node_mem_map) {
unsigned long size, start, end;
struct page *map;
/*
* 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 = start + 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_start_pfn - start);
}
-- Dave
--
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>
next prev parent reply other threads:[~2006-05-04 15:22 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060419112130.GA22648@elte.hu>
[not found] ` <p73aca07whs.fsf@bragg.suse.de>
[not found] ` <20060502070618.GA10749@elte.hu>
[not found] ` <200605020905.29400.ak@suse.de>
[not found] ` <44576688.6050607@mbligh.org>
2006-05-02 14:25 ` assert/crash in __rmqueue() when enabling CONFIG_NUMA Nick Piggin
2006-05-04 1:32 ` Bob Picco
2006-05-04 8:37 ` Ingo Molnar
2006-05-04 9:14 ` Ingo Molnar
2006-05-04 9:26 ` Ingo Molnar
2006-05-04 8:37 ` Andy Whitcroft
2006-05-04 15:21 ` Dave Hansen [this message]
2006-05-04 15:46 ` Bob Picco
2006-05-04 16:07 ` Dave Hansen
2006-05-04 19:25 ` Ingo Molnar
2006-05-04 19:43 ` Bob Picco
2006-05-04 21:50 ` Andy Whitcroft
2006-05-05 5:17 ` Ingo Molnar
2006-05-05 13:55 ` Bob Picco
2006-05-05 14:33 ` Dave Hansen
2006-05-05 14:50 ` Bob Picco
2006-05-05 14:57 ` Dave Hansen
2006-05-05 15:03 ` Martin J. Bligh
2006-05-05 16:22 ` Bob Picco
2006-05-05 16:18 ` Bob Picco
2006-05-06 8:32 ` Nick Piggin
2006-05-07 13:07 ` Andy Whitcroft
2006-05-07 13:18 ` Nick Piggin
2006-05-09 11:05 ` [PATCH 0/3] Zone boundry alignment fixes Andy Whitcroft
2006-05-09 11:05 ` [PATCH 1/3] zone init check and report unaligned zone boundries Andy Whitcroft
2006-05-09 11:28 ` Nick Piggin
2006-05-09 11:05 ` [PATCH 2/3] x86 align highmem zone boundries with NUMA Andy Whitcroft
2006-05-09 11:05 ` [PATCH 3/3] zone allow unaligned zone boundries Andy Whitcroft
2006-05-11 7:59 ` [PATCH 0/3] Zone boundry alignment fixes Andrew Morton
2006-05-12 14:19 ` Ingo Molnar
2006-05-13 1:39 ` Nick Piggin
2006-05-18 14:20 ` [PATCH 0/2] Zone boundary alignment fixes cleanups Andy Whitcroft
2006-05-18 14:21 ` [PATCH 1/2] zone init check and report unaligned zone boundaries fix Andy Whitcroft
2006-05-18 14:21 ` [PATCH 2/2] zone allow unaligned zone boundaries spelling fix Andy Whitcroft
2006-05-18 14:49 ` Andy Whitcroft
2006-05-18 15:54 ` [PATCH 0/2] Zone boundary alignment fixes, cleanups v2 Andy Whitcroft
2006-05-18 15:55 ` [PATCH 1/2] zone init check and report unaligned zone boundaries fix Andy Whitcroft
2006-05-18 15:55 ` [PATCH 2/2] zone allow unaligned zone boundaries spelling fix Andy Whitcroft
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=1146756066.22503.17.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=bob.picco@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).