summaryrefslogtreecommitdiffstats
path: root/include/linux/huge_mm.h
diff options
context:
space:
mode:
authorAndrew Morton <akpm@linux-foundation.org>2011-04-27 15:26:41 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-04-28 11:28:20 -0700
commit6d4831c283530a5f2c6bd8172c13efa236eb149d (patch)
tree4d199a330cfe8710de0deb4e805a798c2982501c /include/linux/huge_mm.h
parente8dad69408a9812d6bb42d03e74d2c314534a4fa (diff)
downloadop-kernel-dev-6d4831c283530a5f2c6bd8172c13efa236eb149d.zip
op-kernel-dev-6d4831c283530a5f2c6bd8172c13efa236eb149d.tar.gz
vfs: avoid large kmalloc()s for the fdtable
Azurit reports large increases in system time after 2.6.36 when running Apache. It was bisected down to a892e2d7dcdfa6c76e6 ("vfs: use kmalloc() to allocate fdmem if possible"). That patch caused the vfs to use kmalloc() for very large allocations and this is causing excessive work (and presumably excessive reclaim) within the page allocator. Fix it by falling back to vmalloc() earlier - when the allocation attempt would have been considered "costly" by reclaim. Reported-by: azurIt <azurit@pobox.sk> Tested-by: azurIt <azurit@pobox.sk> Acked-by: Changli Gao <xiaosuo@gmail.com> Cc: Americo Wang <xiyou.wangcong@gmail.com> Cc: Jiri Slaby <jslaby@suse.cz> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux/huge_mm.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud