summaryrefslogtreecommitdiffstats
path: root/fs/efs/file.c
diff options
context:
space:
mode:
authorRik van Riel <riel@redhat.com>2008-10-18 20:26:36 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-10-20 08:50:26 -0700
commit33c120ed2843090e2bd316de1588b8bf8b96cbde (patch)
tree7a6969fd7aae85fdaa8e63a90494950d8e4a0792 /fs/efs/file.c
parentc5fdae469a6a26cd882d7fe0aa3fbfffb6b72fc5 (diff)
downloadtalos-op-linux-33c120ed2843090e2bd316de1588b8bf8b96cbde.tar.gz
talos-op-linux-33c120ed2843090e2bd316de1588b8bf8b96cbde.zip
more aggressively use lumpy reclaim
During an AIM7 run on a 16GB system, fork started failing around 32000 threads, despite the system having plenty of free swap and 15GB of pageable memory. This was on x86-64, so 8k stacks. If a higher order allocation fails, we can either: - keep evicting pages off the end of the LRUs and hope that we eventually create a contiguous region; this is somewhat unlikely if the system is under enough stress by new allocations - after trying normal eviction for a bit, use lumpy reclaim This patch switches the system to lumpy reclaim if the VM is having trouble freeing enough pages, using the same threshold for detection as used by pageout congestion wait. Signed-off-by: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/efs/file.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud