Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751715AbeACDLW (ORCPT + 1 other); Tue, 2 Jan 2018 22:11:22 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:32772 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbeACDLV (ORCPT ); Tue, 2 Jan 2018 22:11:21 -0500 Subject: Re: [RFC PATCH 1/3] mm, numa: rework do_pages_move To: Michal Hocko , Anshuman Khandual References: <20171207143401.GK20234@dhcp22.suse.cz> <20171208161559.27313-1-mhocko@kernel.org> <20171208161559.27313-2-mhocko@kernel.org> <2e467ad3-a443-bde4-afa2-664bca57914f@linux.vnet.ibm.com> <20180102121237.GC25397@dhcp22.suse.cz> Cc: linux-mm@kvack.org, Zi Yan , Naoya Horiguchi , "Kirill A. Shutemov" , Vlastimil Babka , Andrew Morton , Andrea Reale , LKML From: Anshuman Khandual Date: Wed, 3 Jan 2018 08:41:09 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20180102121237.GC25397@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18010303-0020-0000-0000-000003E600B1 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18010303-0021-0000-0000-000042780E1A Message-Id: <1380d06b-e15b-8fdd-8e31-a6457db634a4@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-03_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801030042 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 01/02/2018 05:42 PM, Michal Hocko wrote: > On Tue 02-01-18 16:55:46, Anshuman Khandual wrote: >> On 12/08/2017 09:45 PM, Michal Hocko wrote: >>> From: Michal Hocko >>> >>> 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); >> } >> > > This is true, except the user will not get this information. Have a look > how we do not copy status on error up in the do_pages_move layer. Ahh, right, we dont. But as you have mentioned this patch does not intend to change the semantics of status return thought it seems like the right thing to do. We can just pass on the status to user here before bailing out.