synchronous lumpy reclaim: wait for page writeback when directly reclaiming contiguou...
commitc661b078fd62abe06fd11fab4ac5e4eeafe26b6d
authorAndy Whitcroft <apw@shadowen.org>
Wed, 22 Aug 2007 21:01:26 +0000 (22 14:01 -0700)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Thu, 23 Aug 2007 02:52:45 +0000 (22 19:52 -0700)
treef21ffeed682900b783563e7d8a8dde906706cc88
parente9187bdcbbc06090757d565a3077e1b0ecab23d2
synchronous lumpy reclaim: wait for page writeback when directly reclaiming contiguous areas

Lumpy reclaim works by selecting a lead page from the LRU list and then
selecting pages for reclaim from the order-aligned area of pages.  In the
situation were all pages in that region are inactive and not referenced by any
process over time, it works well.

In the situation where there is even light load on the system, the pages may
not free quickly.  Out of a area of 1024 pages, maybe only 950 of them are
freed when the allocation attempt occurs because lumpy reclaim returned early.
 This patch alters the behaviour of direct reclaim for large contiguous
blocks.

The first attempt to call shrink_page_list() is asynchronous but if it fails,
the pages are submitted a second time and the calling process waits for the IO
to complete.  This may stall allocators waiting for contiguous memory but that
should be expected behaviour for high-order users.  It is preferable behaviour
to potentially queueing unnecessary areas for IO.  Note that kswapd will not
stall in this fashion.

[apw@shadowen.org: update to version 2]
[apw@shadowen.org: update to version 3]
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/vmscan.c