On Wed, Jun 15, 2011 at 3:57 PM, Ying Han [off-list ref] wrote:

On Fri, Jun 10, 2011 at 12:36 AM, Michal Hocko [off-list ref] wrote:

quoted

On Thu 09-06-11 17:00:26, Michal Hocko wrote:

quoted

On Thu 02-06-11 22:25:29, Ying Han wrote:

quoted

On Thu, Jun 2, 2011 at 2:55 PM, Ying Han [off-list ref] wrote:

quoted

On Tue, May 31, 2011 at 11:25 PM, Johannes Weiner [off-list ref] wrote:

quoted

Currently, soft limit reclaim is entered from kswapd, where it selects

[...]

quoted

quoted

quoted

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c7d4b44..0163840 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c

@@ -1988,9 +1988,13 @@ static void shrink_zone(int priority, struct zone *zone,

               unsigned long reclaimed = sc->nr_reclaimed;
               unsigned long scanned = sc->nr_scanned;
               unsigned long nr_reclaimed;
+               int epriority = priority;
+
+               if (mem_cgroup_soft_limit_exceeded(root, mem))
+                       epriority -= 1;

Here we grant the ability to shrink from all the memcgs, but only
higher the priority for those exceed the soft_limit. That is a design
change
for the "soft_limit" which giving a hint to which memcgs to reclaim
from first under global memory pressure.

Basically, we shouldn't reclaim from a memcg under its soft_limit
unless we have trouble reclaim pages from others.

Agreed.

quoted

Something like the following makes better sense:

diff --git a/mm/vmscan.c b/mm/vmscan.c
index bdc2fd3..b82ba8c 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c

@@ -1989,6 +1989,8 @@ restart:

        throttle_vm_writeout(sc->gfp_mask);
 }

+#define MEMCG_SOFTLIMIT_RECLAIM_PRIORITY       2
+
 static void shrink_zone(int priority, struct zone *zone,
                                struct scan_control *sc)
 {

@@ -2001,13 +2003,13 @@ static void shrink_zone(int priority, struct zone *zone,

                unsigned long reclaimed = sc->nr_reclaimed;
                unsigned long scanned = sc->nr_scanned;
                unsigned long nr_reclaimed;
-               int epriority = priority;

-               if (mem_cgroup_soft_limit_exceeded(root, mem))
-                       epriority -= 1;
+               if (!mem_cgroup_soft_limit_exceeded(root, mem) &&
+                               priority > MEMCG_SOFTLIMIT_RECLAIM_PRIORITY)
+                       continue;

yes, this makes sense but I am not sure about the right(tm) value of the
MEMCG_SOFTLIMIT_RECLAIM_PRIORITY. 2 sounds too low.

There is also another problem. I have just realized that this code path
is shared with the cgroup direct reclaim. We shouldn't care about soft
limit in such a situation. It would be just a wasting of cycles. So we
have to:

if (current_is_kswapd() &&
       !mem_cgroup_soft_limit_exceeded(root, mem) &&
       priority > MEMCG_SOFTLIMIT_RECLAIM_PRIORITY)
       continue;

Agreed.

quoted

Maybe the condition would have to be more complex for per-cgroup
background reclaim, though.

That would be the same logic for per-memcg direct reclaim. In general,
we don't consider soft_limit
unless the global memory pressure. So the condition could be something like:

quoted

if (   global_reclaim(sc) &&
       !mem_cgroup_soft_limit_exceeded(root, mem) &&
       priority > MEMCG_SOFTLIMIT_RECLAIM_PRIORITY)
       continue;

make sense?

Also

+bool mem_cgroup_soft_limit_exceeded(struct mem_cgroup *mem)
+{
+       return res_counter_soft_limit_excess(&mem->res);
+}

--Ying

Thanks

--Ying

quoted

quoted

You would do quite a
lot of loops
(DEFAULT_PRIORITY-MEMCG_SOFTLIMIT_RECLAIM_PRIORITY) * zones * memcg_count
without any progress (assuming that all of them are under soft limit
which doesn't sound like a totally artificial configuration) until you
allow reclaiming from groups that are under soft limit. Then, when you
finally get to reclaiming, you scan rather aggressively.

Maybe something like 3/4 of DEFAULT_PRIORITY? You would get 3 times
over all (unbalanced) zones and all cgroups that are above the limit
(scanning max{1/4096+1/2048+1/1024, 3*SWAP_CLUSTER_MAX} of the LRUs for
each cgroup) which could be enough to collect the low hanging fruit.

--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

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