[lkml]   [2009]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: [Bug #14141] order 2 page allocation failures in iwlagn
    On Wed, Oct 14, 2009 at 08:34:56PM +0200, Frans Pop wrote:
    > Some initial results; all negative I'm afraid.

    These are highly unlikely candidates. I say highly unlikely because they
    are before the page allocator patches when your analysis indicated
    things were ok.

    Commit 70ac23c readahead: sequential mmap readahead
    This affects readahead for mmap() and could have an impact on the
    number of allocations made by the streaming IO. This might be
    generating more bursty network traffic in 2.6.31 than 2.6.30 and
    affecting the allocation apttern enough to cause problems

    Commit 2fad6f5 readahead: enforce full readahead size on async mmap readahead
    Another readahead change that may affect the rate of network
    traffic being generated when streaming IO over the network

    Commit 10be0b3 readahead: introduce context readahead algorithm
    By using readahead in more situations, it again may be affecting
    the burst rate of network traffic and the rate of GFP_ATOMIC arrivals

    Commit 78dc583 vmscan: low order lumpy reclaim also should use PAGEOUT_IO_SYNC
    Very low probability that this is a problem, but it affects
    lumpy reclaim and so has to be considered. It's an awkward
    revert but I think the most important part is just to revert the
    condition that checks if congestion_wait() should be called or not

    I relooked at the page allocator patches themselves just in case. Of the
    patches in there, I came up with

    Commit 11e33f6 page allocator: break up the allocator entry point into fast and slow paths
    This is possibly the most disruptive patch in the set. It should
    not have affected behaviour but the complexity of the patch is
    quite high. I did spot an oddity whereby a process exiting making
    a __GFP_NOFAIL allocation can ignore watermarks. It's unlikely
    this is the problem but as the journal layer uses __GFP_NOFAIL,
    you never know - it might be pushing things down low enough for
    other watermark checks to fail. Patch is below. This is also the
    patch that cause kswapd to wake up less. I sent a patch for that
    problem but I still don't know if it reduced the number of
    failures for you or not.

    Commit f2260e6 page allocator: update NR_FREE_PAGES only as necessary
    This patch affects the timing of when NR_FREE_PAGES is updated.
    The reclaim algorithm makes decisions based on this NR_FREE_PAGES
    value. Crucially, the value can determine if the anon list is force
    scanned or not. The window during which this can make a difference
    should be extremely small but maybe it's enough to make a difference.

    Outside the range of commits suspected of causing problems was the
    following. It's extremely low probability

    Commit 8aa7e84 Fix congestion_wait() sync/async vs read/write confusion
    This patch alters the call to congestion_wait() in the page
    allocator. Frankly, I don't get the change but it might worth
    checking if replacing BLK_RW_ASYNC with WRITE on top of 2.6.31
    makes any difference

    After a lot more eyeballing, the best next candidate within mm is the
    following patch. Should be tested on it's own and in combination with
    the wakeup-kswapd patch sent before.


    From 4e8b5217f51a00caee527e4e8d8e46fe9f82b482 Mon Sep 17 00:00:00 2001
    From: Mel Gorman <>
    Date: Thu, 15 Oct 2009 00:17:05 +0100
    Subject: [PATCH] page allocator: Direct reclaim should always obey watermarks

    ALLOC_NO_WATERMARKS should be cleared when trying to allocate from the
    free-lists after a direct reclaim.

    Signed-off-by: Mel Gorman <>
    mm/page_alloc.c | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

    diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    index 3694609..619933d 100644
    --- a/mm/page_alloc.c
    +++ b/mm/page_alloc.c
    @@ -1920,7 +1920,8 @@ rebalance:
    page = __alloc_pages_direct_reclaim(gfp_mask, order,
    zonelist, high_zoneidx,
    - alloc_flags, preferred_zone,
    + alloc_flags & ~ALLOC_NO_WATERMARKS,
    + preferred_zone,
    migratetype, &did_some_progress);
    if (page)
    goto got_pg;

     \ /
      Last update: 2009-10-15 02:03    [W:0.030 / U:17.156 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site