Messages in this thread | | | Date | Wed, 12 Apr 2006 01:02:10 +0100 (IST) | From | Mel Gorman <> | Subject | Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner |
| |
On Tue, 11 Apr 2006, Bob Picco wrote:
> luck wrote: [Tue Apr 11 2006, 06:20:29PM EDT] >> On Tue, Apr 11, 2006 at 11:39:46AM +0100, Mel Gorman wrote: >> >>> The patches have only been *compile tested* for ia64 with a flatmem >>> configuration. At attempt was made to boot test on an ancient RS/6000 >>> but the vanilla kernel does not boot so I have to investigate there. >> >> The good news: Compilation is clean on the ia64 config variants that >> I usually build (all 10 of them). >> >> The bad (or at least consistent) news: It doesn't boot on an Intel >> Tiger either (oops at kmem_cache_alloc+0x41). >> >> -Tony > I had a reply queued to report the same failure with > DISCONTIG+NUMA+VIRTUAL_MEM_MAP. This was 2 CPU HP rx2600. I'll take a closer > look at the code tomorrow. >
hmm, ok, so discontig.c is in use which narrows things down. When build_node_maps() is called, I assumed that the start and end pfn passed in was for a valid page range. Was this a valid assumption? When I re-read the comment, it implies that memory holes could be within this range which would cause boot failures. If that is the case, the correct thing to do was to call add_active_range() in count_node_pages() instead of build_node_maps().
-- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |