On Tue, Mar 19, 2013 at 07:53:16AM +0800, Simon Jeons wrote: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.Hi Mel,Because of the priority checks made in get_scan_count(). Patch 5 has
On 03/17/2013 09:04 PM, Mel Gorman wrote:
The number of pages kswapd can reclaim is bound by the number of pages itSince there is nr_reclaimed >= nr_to_reclaim check if priority is
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
large than DEF_PRIORITY in shrink_lruvec, how can a large percentage
of memory is suddenly freed happen?
more detail on why this happens.