Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757362AbcC2Pww (ORCPT ); Tue, 29 Mar 2016 11:52:52 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35197 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751927AbcC2Pwu (ORCPT ); Tue, 29 Mar 2016 11:52:50 -0400 Date: Tue, 29 Mar 2016 17:52:47 +0200 From: Michal Hocko To: Andrew Morton Cc: Xishi Qiu , Vlastimil Babka , Joonsoo Kim , David Rientjes , Naoya Horiguchi , Laura Abbott , zhuhui@xiaomi.com, wangxq10@lzu.edu.cn, Linux MM , LKML Subject: Re: [PATCH] mm: fix invalid node in alloc_migrate_target() Message-ID: <20160329155247.GG4466@dhcp22.suse.cz> References: <56F4E104.9090505@huawei.com> <20160325122237.4ca4e0dbca215ccbf4f49922@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160325122237.4ca4e0dbca215ccbf4f49922@linux-foundation.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1556 Lines: 42 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