lkml.org 
[lkml]   [2005]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
    Martin J. Bligh wrote:

    >>But let's move this to another thread if it is going to continue. I
    >>would be happy to discuss scheduler problems.
    >
    >
    > My point was that most things we do add complexity to the codebase,
    > including the things you do yourself ... I'm not saying the we're worse
    > off for the changes you've made, by any means - I think they've been
    > mostly beneficial.

    Heh - I like the "mostly" ;)

    > I'm just pointing out that we ALL do it, so let us
    > not be too quick to judge when others propose adding something that does ;-)
    >

    What I'm getting worried about is the marked increase in the
    rate of features and complexity going in.

    I am almost certainly never going to use memory hotplug or
    demand paging of hugepages. I am pretty likely going to have
    to wade through this code at some point in the future if it
    is merged.

    It is also going to slow down my kernel by maybe 1% when
    doing kbuilds, but hey let's not worry about that until we've
    merged 10 more such slowdowns (ok that wasn't aimed at you or
    Mel, but my perception of the status quo).

    >
    >>You can't what? What doesn't work? If you have no hard limits set,
    >>then the frag patches can't guarantee anything either.
    >>
    >>You can't have it both ways. Either you have limits for things or
    >>you don't need any guarantees. Zones handle the former case nicely,
    >>and we currently do the latter case just fine (along with the frag
    >>patches).
    >
    >
    > I'll go look through Mel's current patchset again. I was under the
    > impression it didn't suffer from this problem, at least not as much
    > as zones did.
    >

    Over time, I don't think it can offer any stronger a guarantee
    than what we currently have. I'm not even sure that it would be
    any better at all for problematic workloads as time -> infinity.

    > Nothing is guaranteed. You can shag the whole machine and/or VM in
    > any number of ways ... if we can significantly improve the probability
    > of existing higher order allocs working, and new functionality has
    > an excellent probability of success, that's as good as you're going to
    > get. Have a free "perfect is the enemy of good" Linus quote, on me ;-)
    >

    I think it falls down if these higher order allocations actually
    get *used* for anything. You'll simply be going through the process
    of replacing your contiguous, easy-to-reclaim memory with pinned
    kernel memory.

    However, for the purpose of memory hot unplug, a new zone *will*
    guarantee memory can be reclaimed and unplugged.

    --
    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-11-02 03:54    [W:3.969 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site