On Mon, Jan 23, 2012 at 7:45 PM, Hillf Danton <dhillf@xxxxxxxxx> wrote: > Hi all > > On Tue, Jan 24, 2012 at 3:04 AM, Ying Han <yinghan@xxxxxxxxxx> wrote: >> On Sun, Jan 22, 2012 at 5:55 PM, Hillf Danton <dhillf@xxxxxxxxx> wrote: >>> To avoid reduction in performance of reclaimee, checking overreclaim is added >>> after shrinking lru list, when pages are reclaimed from mem cgroup. >>> >>> If over reclaim occurs, shrinking remaining lru lists is skipped, and no more >>> reclaim for reclaim/compaction. >>> >>> Signed-off-by: Hillf Danton <dhillf@xxxxxxxxx> >>> --- >>> >>> --- a/mm/vmscan.c Mon Jan 23 00:23:10 2012 >>> +++ b/mm/vmscan.c Mon Jan 23 09:57:20 2012 >>> @@ -2086,6 +2086,7 @@ static void shrink_mem_cgroup_zone(int p >>> unsigned long nr_reclaimed, nr_scanned; >>> unsigned long nr_to_reclaim = sc->nr_to_reclaim; >>> struct blk_plug plug; >>> + bool memcg_over_reclaimed = false; >>> >>> restart: >>> nr_reclaimed = 0; >>> @@ -2103,6 +2104,11 @@ restart: >>> >>> nr_reclaimed += shrink_list(lru, nr_to_scan, >>> mz, sc, priority); >>> + >>> + memcg_over_reclaimed = !scanning_global_lru(mz) >>> + && (nr_reclaimed >= nr_to_reclaim); >>> + if (memcg_over_reclaimed) >>> + goto out; >> >> Why we need the change here? Do we have number to demonstrate? > > See below please 8-) > >> >> >>> } >>> } >>> /* >>> @@ -2116,6 +2122,7 @@ restart: >>> if (nr_reclaimed >= nr_to_reclaim && priority < DEF_PRIORITY) >>> break; >>> } >>> +out: >>> blk_finish_plug(&plug); >>> sc->nr_reclaimed += nr_reclaimed; >>> >>> @@ -2127,7 +2134,8 @@ restart: >>> shrink_active_list(SWAP_CLUSTER_MAX, mz, sc, priority, 0); >>> >>> /* reclaim/compaction might need reclaim to continue */ >>> - if (should_continue_reclaim(mz, nr_reclaimed, >>> + if (!memcg_over_reclaimed && >>> + should_continue_reclaim(mz, nr_reclaimed, >>> sc->nr_scanned - nr_scanned, sc)) >> >> This changes the existing logic. What if the nr_reclaimed is greater >> than nr_to_reclaim, but smaller than pages_for_compaction? The >> existing logic is to continue reclaiming. >> > With soft limit available, what if nr_to_reclaim set to be the number of > pages exceeding soft limit? With over reclaim abused, what are the targets > of soft limit? The nr_to_reclaim is set to SWAP_CLUSTER_MAX (32) for direct reclaim and ULONG_MAX for background reclaim. Not sure we can set it, but it is possible the res_counter_soft_limit_excess equal to that target value. The current soft limit mechanism provides a clue of WHERE to reclaim pages when there is memory pressure, it doesn't change the reclaim target as it was before. Overreclaim a cgroup under its softlimit is bad, but we should be careful not introducing side effect before providing the guarantee. Here, the should_continue_reclaim() has logic of freeing a bit more order-0 pages for compaction. The logic got changed after this. --Ying > Thanks > Hillf -- 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