On Fri, Aug 3, 2012 at 9:16 AM, Rik van Riel [off-list ref] wrote:

On 08/03/2012 11:22 AM, Michal Hocko wrote:

quoted

On Thu 02-08-12 14:24:18, Ying Han wrote:
[...]

quoted

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 3e0d0cd..88487b3 100644
--- a/mm/vmscan.c
+++ 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
+                * - 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 ||
+                               mem_cgroup_over_soft_limit(memcg))
+                       shrink_lruvec(lruvec, sc);

                /*
                 * Limit reclaim has historically picked one memcg and

I am thinking that we could add a constant for the priority
limit. Something like
#define MEMCG_LOW_SOFTLIMIT_PRIORITY    DEF_PRIORITY

Although it doesn't seem necessary at the moment, because there is just
one location where it matters but it could help in the future.
What do you think?

I am working on changing the code to find the "highest priority"
LRU and reclaim from that list first.  That will obviate the need
for such a change. However, the other cleanups and simplifications
made by Ying's patch are good to have...

So what you guys think to take from here. I can make the change as
Michal suggested if that would be something helpful future changes.
However, I wonder whether or not it is necessary.

--Ying

--
All rights reversed

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