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
    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@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:38    [W:3.755 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site