On 08/03/2012 11:22 AM, Michal Hocko wrote:
On Thu 02-08-12 14:24:18, Ying Han wrote: [...]diff --git a/mm/vmscan.c b/mm/vmscan.c index 3e0d0cd..88487b3 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1866,7 +1866,22 @@ static void shrink_zone(struct zone *zone, struct scan_control *sc) do { struct lruvec *lruvec = mem_cgroup_zone_lruvec(zone, memcg); - shrink_lruvec(lruvec, sc); + /* + * Reclaim from mem_cgroup if any of these conditions are met: + * - this is a targetted reclaim ( not global reclaim) + * - reclaim priority is less than DEF_PRIORITY + * - mem_cgroup or its ancestor ( not including root cgroup) + * exceeds its soft limit + * + * Note: The priority check is a balance of how hard to + * preserve the pages under softlimit. If the memcgs of the + * zone having trouble to reclaim pages above their softlimit, + * we have to reclaim under softlimit instead of burning more + * cpu cycles. + */ + if (!global_reclaim(sc) || sc->priority< DEF_PRIORITY || + mem_cgroup_over_soft_limit(memcg)) + shrink_lruvec(lruvec, sc); /* * Limit reclaim has historically picked one memcg andI am thinking that we could add a constant for the priority limit. Something like #define MEMCG_LOW_SOFTLIMIT_PRIORITY DEF_PRIORITY Although it doesn't seem necessary at the moment, because there is just one location where it matters but it could help in the future. What do you think?
I am working on changing the code to find the "highest priority" LRU and reclaim from that list first. That will obviate the need for such a change. However, the other cleanups and simplifications made by Ying's patch are good to have... -- All rights reversed -- 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>