On Wed, 29 Sep 2010, Mel Gorman wrote: > > It's plausible that we never reclaim sufficient memory that we ever get > > above the high watermark since we only trigger reclaim when we can't > > allocate above low, so we may be stuck calling zone_page_state_snapshot() > > constantly. > > > > Except that zone_page_state_snapshot() is only called while kswapd is > awake which is the proxy indicator of pressure. Just being below > percpu_drift_mark is not enough to call zone_page_state_snapshot. > Right, so zone_page_state_snapshot() is always called to check the min watermark for the subsequent allocation immediately after kswapd is kicked in the slow path, meaning it is called for every allocation when the zone is between low and min. That's 360 pages for Shaohua's system and even more if GFP_ATOMIC. kswapd will reclaim to the high watermark, 360 pages above low, using zone_page_state_snapshot() the whole time as well. So under heavy memory pressure, it seems like the majority of zone_watermark_ok() calls are using zone_page_state_snapshot() anyway. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>