summaryrefslogtreecommitdiffstats
path: root/mm/huge_memory.c
diff options
context:
space:
mode:
authorJohannes Weiner <hannes@cmpxchg.org>2011-02-11 00:01:34 +0100
committerLinus Torvalds <torvalds@linux-foundation.org>2011-02-12 01:12:20 +0100
commitf0fdc5e8e6f579310458aef43d1610a0bb5e81a4 (patch)
treec3f9de434bf9065d2f1d7a5f4214f28efb4920c4 /mm/huge_memory.c
parentmlock: do not munlock pages in __do_fault() (diff)
downloadlinux-f0fdc5e8e6f579310458aef43d1610a0bb5e81a4.tar.xz
linux-f0fdc5e8e6f579310458aef43d1610a0bb5e81a4.zip
vmscan: fix zone shrinking exit when scan work is done
Commit 3e7d34497067 ("mm: vmscan: reclaim order-0 and use compaction instead of lumpy reclaim") introduced an indefinite loop in shrink_zone(). It meant to break out of this loop when no pages had been reclaimed and not a single page was even scanned. The way it would detect the latter is by taking a snapshot of sc->nr_scanned at the beginning of the function and comparing it against the new sc->nr_scanned after the scan loop. But it would re-iterate without updating that snapshot, looping forever if sc->nr_scanned changed at least once since shrink_zone() was invoked. This is not the sole condition that would exit that loop, but it requires other processes to change the zone state, as the reclaimer that is stuck obviously can not anymore. This is only happening for higher-order allocations, where reclaim is run back to back with compaction. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Michal Hocko <mhocko@suse.cz> Tested-by: Kent Overstreet<kent.overstreet@gmail.com> Reported-by: Kent Overstreet <kent.overstreet@gmail.com> Acked-by: Mel Gorman <mel@csn.ul.ie> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Rik van Riel <riel@redhat.com> Reviewed-by: Minchan Kim <minchan.kim@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/huge_memory.c')
0 files changed, 0 insertions, 0 deletions