From patchwork Tue Mar 22 21:46:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12789233 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 E13EDC433EF for ; Tue, 22 Mar 2022 21:46:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 780F96B014E; Tue, 22 Mar 2022 17:46:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 730D16B014F; Tue, 22 Mar 2022 17:46:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F8DD6B0150; Tue, 22 Mar 2022 17:46:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 50AFB6B014E for ; Tue, 22 Mar 2022 17:46:09 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 22D8B247A7 for ; Tue, 22 Mar 2022 21:46:09 +0000 (UTC) X-FDA: 79273355658.12.469AA1F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf31.hostedemail.com (Postfix) with ESMTP id 7753420002 for ; Tue, 22 Mar 2022 21:46:08 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6A9BAB81DAD; Tue, 22 Mar 2022 21:46:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00702C340EE; Tue, 22 Mar 2022 21:46:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1647985566; bh=twgtnMsCKbLVHH5ZK/yXbLcXsd805xYGF/oG8kSHFMY=; h=Date:To:From:In-Reply-To:Subject:From; b=X07MdqreJqPOBhicaHrfB0ohQzVYaAAIQ5g+s4jLo+7C93Bhh8qf19o7gq2o0pVCX 5DJhtqRZ0dZyPMQCEafH1nIUEwJPmMBxsgAUr7LPps6vrFyCg0lMZ2Y7xZSmtAdX2+ 41mx0ZK59HcxuRtV8N4KGdZg0cfVQ9DZfKD9rzCc= Date: Tue, 22 Mar 2022 14:46:05 -0700 To: ziy@nvidia.com,zhongjiang-ali@linux.alibaba.com,xlpang@linux.alibaba.com,shy828301@gmail.com,osalvador@suse.de,mgorman@techsingularity.net,dave.hansen@linux.intel.com,baolin.wang@linux.alibaba.com,ying.huang@intel.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220322143803.04a5e59a07e48284f196a2f9@linux-foundation.org> Subject: [patch 149/227] mm,migrate: fix establishing demotion target Message-Id: <20220322214606.00702C340EE@smtp.kernel.org> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7753420002 X-Stat-Signature: fikzfseeymjjdzmpg8z8754h9jf4mrac Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=X07Mdqre; dmarc=none; spf=pass (imf31.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspam-User: X-HE-Tag: 1647985568-710098 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: From: Huang Ying Subject: mm,migrate: fix establishing demotion target 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. Link: https://lkml.kernel.org/r/20220128055940.1792614-1-ying.huang@intel.com Fixes: ac16ec835314 ("mm: migrate: support multiple target nodes demotion") Signed-off-by: "Huang, Ying" Reviewed-by: Baolin Wang Cc: Baolin Wang Cc: Dave Hansen Cc: Zi Yan Cc: Oscar Salvador Cc: Yang Shi Cc: zhongjiang-ali Cc: Xunlei Pang Cc: Mel Gorman Signed-off-by: Andrew Morton --- mm/migrate.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/mm/migrate.c~mmmigrate-fix-establishing-demotion-target +++ a/mm/migrate.c @@ -3079,18 +3079,21 @@ static int establish_migrate_target(int 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; } /*