Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2429156ybl; Sun, 26 Jan 2020 02:28:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwvVaF88t7Czb3w0ti/CCX1Q6KL7iLk1Bijyo7jMs9bc5mckKNp/WnwAVB90ZwOIaCYcnVm X-Received: by 2002:aca:af49:: with SMTP id y70mr4583122oie.162.1580034535452; Sun, 26 Jan 2020 02:28:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580034535; cv=none; d=google.com; s=arc-20160816; b=dIqoQL6+iGiiLdU0zeGpbMBFP2HNynvaQTyE2vXC3J/qrJ+958evI2jDqUcHS+SShz tMNDuwP2eQ9/Rm5J/MKFLup+zLInUUTul6PZK9c+ANUi1FG/+0acspd00T9cQYX2qHht bjibyR6odLDgz8iPcxV8gsdVi8kYPgts/e0oEsFBjZXZxyKlM6v8O3YDV+CsfElaFjYQ tkH6HqzaRBCVriQLrkdjVpYAEsXFWjVrXaOLKkLlZVRz+fYnLt4qnR5lvaqvi+j5DDJO uDkwZkbkVbD238Pkq4tiBaZCaMCNWTFQV9gWKFOHH9DPIufF1WxE3tmNBCOROD6+u1uk xT0w== 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=8avCYKCi1ji5uKL96RtxDyEo/jok4A42fOxa3L404HU=; b=eg0X/XTwrW/3U/+o/8qOfLUBnicLygpehNQ3GOaU+4e1dIHSbywnm2wJDMZa1QHblV LtJyIVa0RLDMlR3YHvCXubVeFhHo1pdlr112vAj2iHZpedJAK7hhoDHsZl7zdAYY62p/ IUDeCvtRwrYGb+oZwv3AW6slt5vfQutje11On/jr5vgX7RFywN/zlA/1MXs01zO+xM86 aXN8eY+pJIanW/FMOIlmyPtS5l96GbP2FTD62MWz36Jgzrbi31ffqb23FAxyL/iYLhpI xCZo3vrqmMnVPokt7ngflSLI/W48deYV2+FZkwX46gYRWxtS6O+Kl4dQ9ZCrMIaOnx8X oCfQ== 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 a3si1201295oid.160.2020.01.26.02.28.40; Sun, 26 Jan 2020 02:28:55 -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 S2387431AbgAZK10 (ORCPT + 99 others); Sun, 26 Jan 2020 05:27:26 -0500 Received: from mga12.intel.com ([192.55.52.136]:33300 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387424AbgAZK1Z (ORCPT ); Sun, 26 Jan 2020 05:27:25 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2020 02:27:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,365,1574150400"; d="scan'208";a="223002745" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by fmsmga008.fm.intel.com with ESMTP; 26 Jan 2020 02:27:23 -0800 From: Wei Yang To: akpm@linux-foundation.org Cc: mhocko@suse.com, yang.shi@linux.alibaba.com, rientjes@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Wei Yang Subject: [Patch v3 4/4] mm/migrate.c: handle same node and add failure in the same way Date: Sun, 26 Jan 2020 18:26:23 +0800 Message-Id: <20200126102623.9616-5-richardw.yang@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200126102623.9616-1-richardw.yang@linux.intel.com> References: <20200126102623.9616-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 b123ced445b7..bb4f45b120fd 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1665,18 +1665,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