Re: [PATCH V7 1/2] mm: memcg softlimit reclaim rework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/30/2012 06:32 PM, Ying Han wrote:

+	for (; memcg; memcg = parent_mem_cgroup(memcg)) {
+		/* This is global reclaim, stop at root cgroup */
+		if (mem_cgroup_is_root(memcg))
+			break;
+		if (res_counter_soft_limit_excess(&memcg->res))
+			return true;
+	}

I like the simplification of mem_cgroup_over_soft_limit.

+++ 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 - 2
+		 * - 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 - 2 ||
+				mem_cgroup_over_soft_limit(memcg))
+			shrink_lruvec(lruvec, sc);

This seems like a bad idea.

Once priority hits DEF_PRIORITY-2, we also end up doing various
other things, like sleeping in the main reclaim loop to wait for
IO to finish. If we use DEF_PRIORITY-1 as the threshold to skip
reclaim when no group is over its soft limit, we may end up
sleeping for nothing, and slowing things down terribly.

Let me try to whip up a quick prototype of the LRU weighing idea
I described at LSF/MM in San Francisco...

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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]