Re: [PATCH 0/6] Sizing zones and holes in an architecture independentmanner V8
From: Mel Gorman
Date: Sun Jul 09 2006 - 11:30:48 EST
On Sat, 8 Jul 2006, Heiko Carstens wrote:
On Sat, Jul 08, 2006 at 12:10:42PM +0100, Mel Gorman wrote:
There are differences in the zone sizes for x86_64 as the arch-specific code
for x86_64 accounts the kernel image and the starting mem_maps as memory
holes but the architecture-independent code accounts the memory as present.
Shouldn't this be the same for all architectures?
The comment in the mail is inaccurate because patch 6/6 will account for
the kernel image and mem_map as holes for all architectures if it is
merged. The patch could be submitted independent of arch-independent
zone-sizing.
Or to put it in other words:
why does only x86_64 account the kernel image as memory hole?
From Andi Kleen's mails in the thread "[PATCH 0/5] Sizing zones and holes
in an architecture independent manner V7"
Begin extract <<<
Why is it a performance regression if the image and memmap is accounted
for as holes? How are those regions different from any other kernel
allocation or bootmem allocations for example which are not accounted as
holes?
They are comparatively big and cannot be freed.
If you are sure that it makes a measurable difference to performance,
There was at least one benchmark/use case where it made a significant
difference, can't remember the exact numbers though.
It affects the low/high water marks in the VM zone balancer.
Especially for the 16MB DMA zone it can make a difference if you
account 4MB kernel in there or not.
End extract <<<
--
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/