• Andrew Barry's avatar
    mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath() · cfa54a0f
    Andrew Barry authored
    I believe I found a problem in __alloc_pages_slowpath, which allows a
    process to get stuck endlessly looping, even when lots of memory is
    available.
    
    Running an I/O and memory intensive stress-test I see a 0-order page
    allocation with __GFP_IO and __GFP_WAIT, running on a system with very
    little free memory.  Right about the same time that the stress-test gets
    killed by the OOM-killer, the utility trying to allocate memory gets stuck
    in __alloc_pages_slowpath even though most of the systems memory was freed
    by the oom-kill of the stress-test.
    
    The utility ends up looping from the rebalance label down through the
    wait_iff_congested continiously.  Because order=0,
    __alloc_pages_direct_compact skips the call to get_page_from_freelist.
    Because all of the reclaimable memory on the system has already been
    reclaimed, __alloc_pages_direct_reclaim skips the call to
    get_page_from_freelist.  Since there is no __GFP_FS flag, the block with
    __alloc_pages_may_oom is skipped.  The loop hits the wait_iff_congested,
    then jumps back to rebalance without ever trying to
    get_page_from_freelist.  This loop repeats infinitely.
    
    The test case is pretty pathological.  Running a mix of I/O stress-tests
    that do a lot of fork() and consume all of the system memory, I can pretty
    reliably hit this on 600 nodes, in about 12 hours.  32GB/node.
    Signed-off-by: default avatarAndrew Barry <abarry@cray.com>
    Signed-off-by: default avatarMinchan Kim <minchan.kim@gmail.com>
    Reviewed-by: Rik van Riel<riel@redhat.com>
    Acked-by: default avatarMel Gorman <mgorman@suse.de>
    Cc: <stable@kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    cfa54a0f
page_alloc.c 158 KB