lkml.org 
[lkml]   [2010]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 11/11] Do not compact within a preferred zone after a compaction failure
    On Tue, Mar 23, 2010 at 01:31:43PM -0500, Christoph Lameter wrote:
    > On Tue, 23 Mar 2010, Mel Gorman wrote:
    >
    > > The fragmentation index may indicate that a failure it due to external
    >
    > s/it/is/
    >

    Correct.

    > > fragmentation, a compaction run complete and an allocation failure still
    >
    > ???
    >

    I was having some sort of fit when I wrote that obviously. Try this on
    for size

    The fragmentation index may indicate that a failure is due to external
    fragmentation but after a compaction run completes, it is still possible
    for an allocation to fail.

    > > fail. There are two obvious reasons as to why
    > >
    > > o Page migration cannot move all pages so fragmentation remains
    > > o A suitable page may exist but watermarks are not met
    > >
    > > In the event of compaction and allocation failure, this patch prevents
    > > compaction happening for a short interval. It's only recorded on the
    >
    > compaction is "recorded"? deferred?
    >

    deferred makes more sense.

    What I was thinking at the time was that compact_resume was stored in struct
    zone - i.e. that is where it is recorded.

    > > preferred zone but that should be enough coverage. This could have been
    > > implemented similar to the zonelist_cache but the increased size of the
    > > zonelist did not appear to be justified.
    >
    > > @@ -1787,6 +1787,9 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
    > > */
    > > count_vm_event(COMPACTFAIL);
    > >
    > > + /* On failure, avoid compaction for a short time. */
    > > + defer_compaction(preferred_zone, jiffies + HZ/50);
    > > +
    >
    > 20ms? How was that interval determined?
    >

    Matches the time the page allocator would defer to an event like
    congestion. The choice is somewhat arbitrary. Ideally, there would be
    some sort of event that would re-enable compaction but there wasn't an
    obvious candidate so I used time.

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


    \
     
     \ /
      Last update: 2010-03-23 19:43    [W:4.062 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site