[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2e467ad3-a443-bde4-afa2-664bca57914f@linux.vnet.ibm.com>
Date: Tue, 2 Jan 2018 16:55:46 +0530
From: Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To: Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org
Cc: Zi Yan <zi.yan@...rutgers.edu>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Vlastimil Babka <vbabka@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrea Reale <ar@...ux.vnet.ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
Michal Hocko <mhocko@...e.com>
Subject: Re: [RFC PATCH 1/3] mm, numa: rework do_pages_move
On 12/08/2017 09:45 PM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@...e.com>
>
> do_pages_move is supposed to move user defined memory (an array of
> addresses) to the user defined numa nodes (an array of nodes one for
> each address). The user provided status array then contains resulting
> numa node for each address or an error. The semantic of this function is
> little bit confusing because only some errors are reported back. Notably
> migrate_pages error is only reported via the return value. This patch
It does report back the migration failures as well. In new_page_node
there is '*result = &pm->status' which going forward in unmap_and_move
will hold migration error or node ID of the new page.
newpage = get_new_page(page, private, &result);
............
if (result) {
if (rc)
*result = rc;
else
*result = page_to_nid(newpage);
}
Powered by blists - more mailing lists