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

[Andrew Morton]

Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
>
> 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.

Remember that Rohit is seeing ~10% variation between runs of scientific
software, and that his patch to use higher-order pages to preload the
percpu-pages magazines fixed that up.  I assume this means that it provided
up to 10% speedup, which is a lot.

But the patch caused page allocator fragmentation and several reports of
gigE Tx buffer allocation failures, so I dropped it.

We think that Mel's patches will allow us to reintroduce Rohit's
optimisation.

> 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.
> 

But yes, adding additional complexity is a black mark, and these patches
add quite a bit.  (Ditto the fine-looking adaptive readahead patches, btw).
-
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/