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
    Andrew Morton wrote:
    > Nick Piggin <nickpiggin@yahoo.com.au> wrote:

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

    OK, I wasn't aware of this. I wonder what other approaches we could
    try to add a bit of colour to our pages? I bet something simple like
    trying to hand out alternate odd/even pages per task might help.

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

    They do look quite fine. They seem to get their claws pretty deep
    into page reclaim, but I guess that is to be expected if we want
    to increase readahead smarts much more.

    However, I'm hoping bits of that can be merged at a time, and
    interfaces and page reclaim stuff can be discussed and the best
    option taken. No such luck with these patches AFAIKS - simply
    adding another level of page groups, and another level of
    heuristics to the page allocator is going to hurt. By definition.
    I do wonder why zones can't be used... though I'm sure there are
    good reasons.

    --
    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 08:12    [W:0.026 / U:0.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site