From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 279D8C433F5 for ; Mon, 7 Feb 2022 01:37:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 619166B0072; Sun, 6 Feb 2022 20:37:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A0FA6B0073; Sun, 6 Feb 2022 20:37:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41BD16B0074; Sun, 6 Feb 2022 20:37:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 2B3946B0072 for ; Sun, 6 Feb 2022 20:37:52 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CF885181E8E6B for ; Mon, 7 Feb 2022 01:37:51 +0000 (UTC) X-FDA: 79114272342.25.F33D4EF Received: from out30-54.freemail.mail.aliyun.com (out30-54.freemail.mail.aliyun.com [115.124.30.54]) by imf13.hostedemail.com (Postfix) with ESMTP id 3A0DB20003 for ; Mon, 7 Feb 2022 01:37:49 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0V3inHOV_1644197863; Received: from 30.21.164.20(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0V3inHOV_1644197863) by smtp.aliyun-inc.com(127.0.0.1); Mon, 07 Feb 2022 09:37:44 +0800 Message-ID: <07970c9c-9816-650b-26ab-ed9aa46d0653@linux.alibaba.com> Date: Mon, 7 Feb 2022 09:38:44 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] mm,migrate: fix establishing demotion target To: Huang Ying , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Hansen , Zi Yan , Oscar Salvador , Yang Shi , zhongjiang-ali , Xunlei Pang References: <20220128055940.1792614-1-ying.huang@intel.com> From: Baolin Wang In-Reply-To: <20220128055940.1792614-1-ying.huang@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3A0DB20003 X-Stat-Signature: 9k5a1xdy5gws7mqn7d3nw8hqwwu6tpa9 Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.54 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com X-Rspam-User: nil X-HE-Tag: 1644197869-225598 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 1/28/2022 1:59 PM, Huang Ying wrote: > In commit ac16ec835314 ("mm: migrate: support multiple target nodes > demotion"), after the first demotion target node is found, we will > continue to check the next candidate obtained via > find_next_best_node(). This is to find all demotion target nodes with > same NUMA distance. But one side effect of find_next_best_node() is > that the candidate node returned will be set in "used" parameter, even > if the candidate node isn't passed in the following NUMA distance > checking, the candidate node will not be used as demotion target node > for the following nodes. For example, for system as follows, > > node distances: > node 0 1 2 3 > 0: 10 21 17 28 > 1: 21 10 28 17 > 2: 17 28 10 28 > 3: 28 17 28 10 > > when we establish demotion target node for node 0, in the first round > node 2 is added to the demotion target node set. Then in the second > round, node 3 is checked and failed because distance(0, 3) > > distance(0, 2). But node 3 is set in "used" nodemask too. When we > establish demotion target node for node 1, there is no available node. > This is wrong, node 3 should be set as the demotion target of node 1. > > To fix this, if the candidate node is failed to pass the distance > checking, it will be cleared in "used" nodemask. So that it can be > used for the following node. > > The bug can be reproduced and fixed with this patch on a 2 socket > server machine with DRAM and PMEM. > > Fixes: ac16ec835314 ("mm: migrate: support multiple target nodes demotion") > Signed-off-by: "Huang, Ying" > Cc: Baolin Wang > Cc: Dave Hansen > Cc: Zi Yan > Cc: Oscar Salvador > Cc: Yang Shi > Cc: Baolin Wang > Cc: zhongjiang-ali > Cc: Xunlei Pang > --- Good catch. Thanks. Reviewed-by: Baolin Wang > mm/migrate.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index c7da064b4781..e8a6933af68d 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -3082,18 +3082,21 @@ static int establish_migrate_target(int node, nodemask_t *used, > if (best_distance != -1) { > val = node_distance(node, migration_target); > if (val > best_distance) > - return NUMA_NO_NODE; > + goto out_clear; > } > > index = nd->nr; > if (WARN_ONCE(index >= DEMOTION_TARGET_NODES, > "Exceeds maximum demotion target nodes\n")) > - return NUMA_NO_NODE; > + goto out_clear; > > nd->nodes[index] = migration_target; > nd->nr++; > > return migration_target; > +out_clear: > + node_clear(migration_target, *used); > + return NUMA_NO_NODE; > } > > /*