Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

From: Nick Piggin
Date: Mon Oct 31 2005 - 01:36:17 EST


Mike Kravetz wrote:
On Sun, Oct 30, 2005 at 06:33:55PM +0000, Mel Gorman wrote:

Here are a few brief reasons why this set of patches is useful;

o Reduced fragmentation improves the chance a large order allocation succeeds
o General-purpose memory hotplug needs the page/memory groupings provided
o Reduces the number of badly-placed pages that page migration mechanism must
deal with. This also applies to any active page defragmentation mechanism.


I can say that this patch set makes hotplug memory remove be of
value on ppc64. My system has 6GB of memory and I would 'load
it up' to the point where it would just start to swap and let it
run for an hour. Without these patches, it was almost impossible
to find a section that could be offlined. With the patches, I
can consistently reduce memory to somewhere between 512MB and 1GB.
Of course, results will vary based on workload. Also, this is
most advantageous for memory hotlug on ppc64 due to relatively
small section size (16MB) as compared to the page grouping size
(8MB). A more general purpose solution is needed for memory hotplug
support on architectures with larger section sizes.

Just another data point,

Despite what people were trying to tell me at Ottawa, this patch
set really does add quite a lot of complexity to the page
allocator, and it seems to be increasingly only of benefit to
dynamically allocating hugepages and memory hot unplug.

If that is the case, do we really want to make such sacrifices
for the huge machines that want these things? What about just
making an extra zone for easy-to-reclaim things to live in?

This could possibly even be resized at runtime according to
demand with the memory hotplug stuff (though I haven't been
following that).

Don't take this as criticism of the actual implementation or its
effectiveness.

Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com -
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/