Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4303874ybl; Tue, 21 Jan 2020 17:20:11 -0800 (PST) X-Google-Smtp-Source: APXvYqw779r2hY6x6DwQmiOG6+qe927Pe+83XtfmB3TB4iPaRfKEXwSemJh0ZxYfyhptASXOACDb X-Received: by 2002:a9d:3f61:: with SMTP id m88mr5510965otc.56.1579656011333; Tue, 21 Jan 2020 17:20:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579656011; cv=none; d=google.com; s=arc-20160816; b=GlYxsUCwC7I6in7Np9lIDmsBI1XeEpvFf/F672uVSChOdeV4GGgr2qbTRaTE+BlO9b N0kiBcoHphwtoDq3fowEWH3ZeAyST/NQWs4xcen9VWg/EymmxiQxHUECLm6VvVC3LxoI qsgI3Z0a/TCN2u0PF4X78qmNR/6+3KDcNVNlY1syK1iJVepkN9krdDaKHARoT0AGEYET ejDkB1XlsiRLcMzHMnhEl/f/nNsrz2a+OXHLidBRi07ky0tcQ61HbOwjlfSIr7UpDWZL o7f8LuAdTQpYvqvU4jQF/846lDI+8H1KR2fPgcPC1bdPU7QSCF31NK5pdurjOY545Q43 0RnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=Y8Ns1xnXmjuMcKQecKgnUidpmeeDJJ/P7ufGhIqIPhU=; b=tfDIxI8uJDpQIFDXOnNwvFIk/PvHrgzk1PF8vcRA9DyBGgnEjyamvgpUhHoGWpOKPP 1V23R9U3t3EFB3kFLjM3nRb3hP4yisr3mXo/UYB9IIusc6JRecbRt7GpYQo03X2Ku1dk ZPiuLIZFPd+sC3fegTe6Ps/DBAlZHjlgJxzQnaORKsHPKwvu9y3wbAJIPmIjul8saYHE jp82HziX8X5m/zFbudwZrjzShsdmNO/kCWaw9+p7QV2elhorMoDlmPor7sWq0Q/hwEi2 ro8gyqFW6KYLYeYhgDAsj6ShcXR1vkTkDiwl5E/F6dQF6tBeifcamWhjGfIXhjNA7rL1 s4iw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s68si21795283oih.275.2020.01.21.17.19.59; Tue, 21 Jan 2020 17:20:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729144AbgAVBRU (ORCPT + 99 others); Tue, 21 Jan 2020 20:17:20 -0500 Received: from mga06.intel.com ([134.134.136.31]:24737 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729113AbgAVBRQ (ORCPT ); Tue, 21 Jan 2020 20:17:16 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2020 17:17:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,347,1574150400"; d="scan'208";a="244885539" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by orsmga002.jf.intel.com with ESMTP; 21 Jan 2020 17:17:14 -0800 From: Wei Yang To: akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, mhocko@suse.com, yang.shi@linux.alibaba.com, rientjes@google.com, Wei Yang Subject: [Patch v2 4/4] mm/migrate.c: handle same node and add failure in the same way Date: Wed, 22 Jan 2020 09:16:47 +0800 Message-Id: <20200122011647.13636-5-richardw.yang@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200122011647.13636-1-richardw.yang@linux.intel.com> References: <20200122011647.13636-1-richardw.yang@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When page is not queued for migration, there are two possible cases: * page already on the target node * failed to add to migration queue Current code handle them differently, this leads to a behavior inconsistency. Usually for each page's status, we just do store for once. While for the page already on the target node, we might store the node information for twice: * once when we found the page is on the target node * second when moving the pages to target node successfully after above action The reason is even we don't add the page to pagelist, but store_status() does store in a range which still contains the page. This patch handles these two cases in the same way to reduce this inconsistency and also make the code a little easier to read. Signed-off-by: Wei Yang Acked-by: Michal Hocko --- mm/migrate.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index 80d2bba57265..591f2e5caed6 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1654,18 +1654,18 @@ static int do_pages_move(struct mm_struct *mm, nodemask_t task_nodes, err = add_page_for_migration(mm, addr, current_node, &pagelist, flags & MPOL_MF_MOVE_ALL); - if (!err) { - /* The page is already on the target node */ - err = store_status(status, i, current_node, 1); - if (err) - goto out_flush; - continue; - } else if (err > 0) { + if (err > 0) { /* The page is successfully queued for migration */ continue; } - err = store_status(status, i, err, 1); + /* + * Two possible cases for err here: + * == 0: page is already on the target node, then store + * current_node to status + * < 0: failed to add page to list, then store err to status + */ + err = store_status(status, i, err ? : current_node, 1); if (err) goto out_flush; -- 2.17.1