Messages in this thread Patch in this message | | | Date | Thu, 13 Apr 2006 20:14:02 +0100 | Subject | Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2 | From | (Mel Gorman) |
| |
On (13/04/06 10:47), Luck, Tony didst pronounce: > > Double counted a hole here, then went downhill. Does the following fix > > it? > > Yes, that boots. What's more the counts of pages in DMA/Normal > zone match the kernel w/o your patches too. So for tiger_defconfig > you've now exactly matched the old behaivour. >
Very very cool. Thanks for persisting.
> I'll try to test generic and sparse kernels later, but I have to > look at another issue now. >
When you get around to it later, there is one case you may hit that Bob Picco encountered and fixed for me. It's where a "new" range is registered that is inside an existing area; e.g.
add_active_range: 0->10000 add_active_range: 9800->10000
It ends up merging incorrectly and you end up with one region from 9800-10000. The fix is below.
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-zonesizing-v6/mm/mem_init.c linux-2.6.17-rc1-107-debug/mm/mem_init.c --- linux-2.6.17-rc1-zonesizing-v6/mm/mem_init.c 2006-04-13 10:30:50.000000000 +0100 +++ linux-2.6.17-rc1-107-debug/mm/mem_init.c 2006-04-13 18:39:24.000000000 +0100 @@ -922,6 +926,13 @@ void __init add_active_range(unsigned in if (early_node_map[i].nid != nid) continue; + /* Skip if an existing region covers this new one */ + if (start_pfn >= early_node_map[i].start_pfn && + end_pfn <= early_node_map[i].end_pfn) { + printk("Existing\n"); + return; + } + /* Merge forward if suitable */ if (start_pfn <= early_node_map[i].end_pfn && end_pfn > early_node_map[i].end_pfn) { - 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/
| |