On Fri 25-03-16 12:22:37, Andrew Morton wrote: [...] > And can someone please explain mem_cgroup_select_victim_node() to me? > How can we hit the "node = numa_node_id()" path? Only if > memcg->scan_nodes is empty? Yes, this seems to be the primary motivation. mem_cgroup_may_update_nodemask might have seen all the pages on unevictable LRU last time it checked something. > is that even valid? I suspect it is really rare but it seems possible > 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. Would something like the following be more clear? --- diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 17a847c96618..cff095318950 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1390,10 +1390,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(); -- Michal Hocko SUSE Labs -- 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>