lkml.org 
[lkml]   [2005]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
    Nick Piggin <nickpiggin@yahoo.com.au> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-10-31 07:57    [W:2.917 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site