Re: [PATCH] mm: vmscan: check mem cgroup over reclaimed

On Mon, Jan 23, 2012 at 7:45 PM, Hillf Danton [off-list ref] wrote:

Hi all

On Tue, Jan 24, 2012 at 3:04 AM, Ying Han [off-list ref] wrote:

quoted

On Sun, Jan 22, 2012 at 5:55 PM, Hillf Danton [off-list ref] wrote:

quoted

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 <redacted>
---

--- 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-)

quoted

quoted

                       }
               }
               /*

@@ -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@kvack.org.  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=mailto:"dont@kvack.org"> email@kvack.org </a>