Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2

On (13/04/06 14:53), Luck, Tony didst pronounce:
On Thu, Apr 13, 2006 at 08:14:02PM +0100, Mel Gorman wrote:
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.

I applied that fix on top of all the others and re-built and booted
a "generic" kernel (using arch/ia64/defconfig) and a "sparse" kernel
(based on arch/ia64/configs/gensparse_defconfig).

Both booted just fine on my tiger, the memory amounts looked
a bit suspicious though ... as if you are reporting *all* the
memory in range for the zone, rather than the usable parts.

Diffing console log from the boot of a 2.6.17-rc1 generic
kernel against one with your patches the relevent bit is:

< On node 0 totalpages: 259873
< DMA zone: 128931 pages, LIFO batch:7
< Normal zone: 130942 pages, LIFO batch:7
---
On node 0 totalpages: 262144
DMA zone: 131072 pages, LIFO batch:7
Normal zone: 131072 pages, LIFO batch:7

That's a very precise 4G total, split exactly 2G+2G between
DMA and normal zones. Same thing for the sparse kernel
(though I didn't check what an unpatched kernel prints).


Interesting. I register active ranges inside count_node_pages() which is an
EFI memmap_walk callback. So, I'd expect to see one call to add_active_range()
for each active range in the EFI map;

add_active_range(0, 0, 4096): New
add_active_range(0, 0, 131072): Merging forward
add_active_range(0, 0, 131072): Existing
add_active_range(0, 393216, 523264): New
add_active_range(0, 393216, 523264): Existing
add_active_range(0, 393216, 524288): Merging forward
add_active_range(0, 393216, 524288): Existing

That appears fine, but I call add_active_range() after a GRANULEROUNDUP and
GRANULEROUNDDOWN has taken place so that might be the problem, especially as
all those ranges are aligned on a 16MiB boundary. The following patch calls
add_active_range() before the rounding takes place. Can you try it out please?

diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-zonesizing-v6/arch/ia64/mm/discontig.c linux-2.6.17-rc1-107-debug/arch/ia64/mm/discontig.c
--- linux-2.6.17-rc1-zonesizing-v6/arch/ia64/mm/discontig.c 2006-04-13 10:30:49.000000000 +0100
+++ linux-2.6.17-rc1-107-debug/arch/ia64/mm/discontig.c 2006-04-14 11:37:51.000000000 +0100
@@ -636,6 +636,7 @@ static __init int count_node_pages(unsig
{
unsigned long end = start + len;

+ add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
mem_data[node].num_physpages += len >> PAGE_SHIFT;
if (start <= __pa(MAX_DMA_ADDRESS))
mem_data[node].num_dma_physpages +=
@@ -647,7 +648,6 @@ static __init int count_node_pages(unsig
end >> PAGE_SHIFT);
mem_data[node].min_pfn = min(mem_data[node].min_pfn,
start >> PAGE_SHIFT);
- add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);

return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/