On Thu, Apr 12, 2012 at 7:24 AM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > On Wed, Apr 11, 2012 at 09:06:27PM -0700, Ying Han wrote: >> On Wed, Apr 11, 2012 at 4:56 PM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: >> > On Wed, Apr 11, 2012 at 03:00:27PM -0700, Ying Han wrote: >> >> Under global background reclaim, the sc->nr_to_reclaim is set to >> >> ULONG_MAX. Now we are iterating all memcgs under the zone and we >> >> shouldn't pass the pressure from kswapd for each memcg. >> >> >> >> After all, the balance_pgdat() breaks after reclaiming SWAP_CLUSTER_MAX >> >> pages to prevent building up reclaim priorities. >> > >> > shrink_mem_cgroup_zone() bails out of a zone, balance_pgdat() bails >> > out of a priority loop, there is quite a difference. >> > >> > After this patch, kswapd no longer puts equal pressure on all zones in >> > the zonelist, which was a key reason why we could justify bailing >> > early out of individual zones in direct reclaim: kswapd will restore >> > fairness. >> >> Guess I see your point here. >> >> My intention is to prevent over-reclaim memcgs per-zone by having >> nr_to_reclaim to ULONG_MAX. Now, we scan each memcg based on >> get_scan_count() without bailout, do you see a problem w/o this patch? > > The fact that we iterate over each memcg does not make a difference, > because the target that get_scan_count() returns for each zone-memcg > is in sum what it would have returned for the whole zone, so the scan > aggressiveness did not increase. It just distributes the zone's scan > target over the set of memcgs proportional to their share of pages in > that zone. > > So I have trouble deciding what's right. > > On the one hand, I don't see why you bother with this patch, because > you don't increase the risk of overreclaim. Michal's concern for > overreclaim came from the fact that I had kswapd do soft limit reclaim > at priority 0 without ever bailing from individual zones. But your > soft limit implementation is purely about selecting memcgs to reclaim, > you never increase the pressure put on a memcg anywhere. I agree w/ you here. > > On the other hand, I don't even agree with that aspect of your series; > that you no longer prioritize explicitely soft-limited groups in > excess over unconfigured groups, as I mentioned in the other mail. > But if you did, you would likely need a patch like this, I think. Prioritize between memcg w/ default softlimit (0) and memcg exceeds non-default softlimit (x) ? Are you referring to the balance the reclaim between eligible memcgs based on different factors like softlimit_exceed, recent_scanned, recent_reclaimed....? If so, I am planning to make that as second step after this patch series. --Ying -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href