On Sat, 8 Jul 2006, Heiko Carstens wrote:

On Sat, Jul 08, 2006 at 12:10:42PM +0100, Mel Gorman wrote:

quoted

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"

quoted

quoted

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.

quoted

quoted

End extract <<<

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab