mm/memcontrol.c:mem_cgroup_select_victim_node(): clarify comment
authorMichal Hocko <mhocko@kernel.org>
Fri, 20 May 2016 00:11:34 +0000 (17:11 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 20 May 2016 02:12:14 +0000 (19:12 -0700)
> The comment seems to have not much to do with the code?

I guess the comment tries to say that the code path is triggered when we
charge the page which happens _before_ it is added to the LRU list and
so last_scanned_node might contain the stale data.

Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/memcontrol.c

index 6740c4c2b550a0da5bc13c1288042163df61b17a..011dac8ab5d739b79612473bc20e599f6c63c791 100644 (file)
@@ -1391,10 +1391,9 @@ int mem_cgroup_select_victim_node(struct mem_cgroup *memcg)
 
        node = next_node_in(node, memcg->scan_nodes);
        /*
-        * We call this when we hit limit, not when pages are added to LRU.
-        * No LRU may hold pages because all pages are UNEVICTABLE or
-        * memcg is too small and all pages are not on LRU. In that case,
-        * we use curret node.
+        * mem_cgroup_may_update_nodemask might have seen no reclaimmable pages
+        * last time it really checked all the LRUs due to rate limiting.
+        * Fallback to the current node in that case for simplicity.
         */
        if (unlikely(node == MAX_NUMNODES))
                node = numa_node_id();