lkml.org 
[lkml]   [2010]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/8] mm: migration: Allow migration to operate asynchronously and avoid synchronous compaction in the faster path
    On Thu, Nov 18, 2010 at 07:21:06PM +0100, Andrea Arcangeli wrote:
    > On Wed, Nov 17, 2010 at 04:22:45PM +0000, Mel Gorman wrote:
    > > @@ -484,6 +486,7 @@ static unsigned long compact_zone_order(struct zone *zone,
    > > .order = order,
    > > .migratetype = allocflags_to_migratetype(gfp_mask),
    > > .zone = zone,
    > > + .sync = false,
    > > };
    > > INIT_LIST_HEAD(&cc.freepages);
    > > INIT_LIST_HEAD(&cc.migratepages);
    >
    > I like this because I'm very afraid to avoid wait-I/O latencies
    > introduced into hugepage allocations that I prefer to fail quickly and
    > be handled later by khugepaged ;).
    >

    As you can see from the graphs in the leader, it makes a big difference to
    latency as well to avoid sync migration where possible.

    > But I could have khugepaged call this with sync=true... so I'd need a
    > __GFP_ flag that only khugepaged would use to notify compaction should
    > be synchronous for khugepaged (not for the regular allocations in page
    > faults). Can we do this through gfp_mask only?
    >

    We could pass gfp flags in I guess and abuse __GFP_NO_KSWAPD (from the THP
    series obviously)?

    > > @@ -500,6 +503,7 @@ unsigned long reclaimcompact_zone_order(struct zone *zone,
    > > .order = order,
    > > .migratetype = allocflags_to_migratetype(gfp_mask),
    > > .zone = zone,
    > > + .sync = true,
    > > };
    > > INIT_LIST_HEAD(&cc.freepages);
    > > INIT_LIST_HEAD(&cc.migratepages);
    >
    > Is this intentional?

    Yes, it's the "slower" path where we've already reclaim pages and more
    willing to wait for the compaction to occur as the alternative is failing
    the allocation.

    > That inner compaction invocation is
    > equivalent to the one one interleaved with the shrinker tried before
    > invoking the shrinker. So I don't see why they should differ (one sync
    > and one async).
    >

    The async one later in the series becomes very light with the heavier
    work being done within reclaim if necessary.

    > Anyway I'd prefer the inner invocation to be removed as a whole and to
    > keep only going with the interleaving and to keep the two jobs of
    > compaction and shrinking memory fully separated and to stick to the
    > interleaving. If this reclaimcompact_zone_order helps maybe it means
    > compact_zone_order isn't doing the right thing and we're hiding it by
    > randomly calling it more frequently...
    >

    I'll think about it more. I could just leave it at try_to_compact_pages
    doing the zonelist scan although it's not immediately occuring to me how I
    should decide between sync and async other than "async the first time and
    sync after that". The allocator does not have the same "reclaim priority"
    awareness that reclaim does.

    > I can see a point however in doing:
    >
    > compaction async
    > shrink (may wait) (scan 500 pages, freed 32 pages)
    > compaction sync (may wait)
    >
    > to:
    >
    > compaction async
    > shrink (scan 32 pages, freed 0 pages)
    > compaction sync (hugepage generated nobody noticed)
    > shrink (scan 32 pages, freed 0 pages)
    > compaction sync
    > shrink (scan 32 pages, freed 0 pages)
    > [..]
    >

    --
    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab


    \
     
     \ /
      Last update: 2010-11-18 19:37    [W:2.511 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site