lkml.org 
[lkml]   [2005]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
    On Wed, 2 Nov 2005, Nick Piggin wrote:

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

    Plenty of features in the kernel I don't use either :) .

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

    Ok, my patches show performance gains and losses on different parts of
    Aim9. page_test is slightly down but fork_test was considerably up. Both
    would have an effect on kbuild so more figures are needed on mode
    machines. That will only be found from testing from a variety of machines.

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

    Not as they currently stand no. As I've said elsewhere, to really
    guarantee things, kswapd would need to know how to clear out UesrRclm
    pages from the other reserve types.

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

    And a misconfigured zone-based approach just falls apart. Going to finish
    that summary mail to avoid repetition.

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

    >

    --
    Mel Gorman
    Part-time Phd Student Java Applications Developer
    University of Limerick IBM Dublin Software Lab
    -
    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 12:51    [W:0.034 / U:1.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site