Hi Mel,
On 03/19/2013 05:55 PM, Mel Gorman wrote:
On Tue, Mar 19, 2013 at 07:53:16AM +0800, Simon Jeons wrote:
Hi Mel,
On 03/17/2013 09:04 PM, Mel Gorman wrote:
The number of pages kswapd can reclaim is bound by the number of pages it
scans which is related to the size of the zone and the scanning priority. In
many cases the priority remains low because it's reset every SWAP_CLUSTER_MAX
reclaimed pages but in the event kswapd scans a large number of pages it
cannot reclaim, it will raise the priority and potentially discard a large
percentage of the zone as sc->nr_to_reclaim is ULONG_MAX. The user-visible
effect is a reclaim "spike" where a large percentage of memory is suddenly
freed. It would be bad enough if this was just unused memory but because
Since there is nr_reclaimed >= nr_to_reclaim check if priority is
large than DEF_PRIORITY in shrink_lruvec, how can a large percentage
of memory is suddenly freed happen?
Because of the priority checks made in get_scan_count(). Patch 5 has
more detail on why this happens.
But nr_reclaim >= nr_to_reclaim check in function shrink_lruvec is after
scan each evictable lru, so if priority == 0, still scan the whole world.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>