Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4569232ybl; Wed, 22 Jan 2020 00:09:08 -0800 (PST) X-Google-Smtp-Source: APXvYqwmrJvZo0wuQy8APc4fLbN30Sqo6F6KdMjytu4yu5rnwjmFZ6/7uCnCHJp5SKJ1tIfkJO9q X-Received: by 2002:aca:ec4f:: with SMTP id k76mr5719250oih.156.1579680547903; Wed, 22 Jan 2020 00:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579680547; cv=none; d=google.com; s=arc-20160816; b=z/NMxxffnE7AOQaTqkp2bp1K9VAqDhZ45v1htqynnv1j0fL1fUVePNJENsMl5Ka9Kd w+R8y2G7tv009xc4JkkezaSsdEeLh3hcxQUGMCozU7UhwBcbNhfeNG5wn9PrNN1UWbQb WCfAp1+BNYDMaugOhXCB3X5+bBeMJHWHq7wtyU9bBg66hA9Wjj1DgA29zbPM/JJwGzcN YS5N86kHjCxsJdasWr/B3C7Thb1ZwZ9zJFCQHDhM9ipu0p/ffcip1kEr2onUuofj0vGJ qH7XmkyEHVANefqT6jn83C5dPRvlBNa9nhi/RMzPf6An5qmtmVzucH+xoHMHbcPmcf9y Co1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=yQD6BMfgsUB2zOq+Dz3vFA3XMaEJr7rjWMT5V31lJ5U=; b=YjJOI/JWLtkndhT/JvRqXslMiHAImoetVPjAAAwGG5UHbZHX4xwWaDIWghCz6igSS8 YSQb2zuxsPE1SxTLXlGLxrodxj+W4r/nd5Kj4GzBbzRXi1h2CEK6FK7aSMhUUQZPmG0X 1kkR+TDMopC8cY9uir4DXajE85BYUaDBf0rXIZVxSVWwJHjet0CCfL+1saDAsLgGv3bx dn44BDsiBU+4SJmh+YvJBM2crzh+FeUrk3BPdYYxmiVkIKa/v+1mCprWplyl8AycwY1X eIovuXnMokEUEA8LT8PZ7LzUQsyYBy8vV7IxWh8NpxTr1DbDiWufCt/tIgj6/vHn9J6S N57w== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e3si23207133otr.245.2020.01.22.00.08.55; Wed, 22 Jan 2020 00:09:07 -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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726026AbgAVIG5 (ORCPT + 99 others); Wed, 22 Jan 2020 03:06:57 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:36332 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725868AbgAVIG5 (ORCPT ); Wed, 22 Jan 2020 03:06:57 -0500 Received: by mail-wm1-f67.google.com with SMTP id p17so6114430wma.1; Wed, 22 Jan 2020 00:06:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=yQD6BMfgsUB2zOq+Dz3vFA3XMaEJr7rjWMT5V31lJ5U=; b=ZBu6YbsZXpXW8FW+V/QXVy9LG1vHdZlIpNTchpPtw9k6TpMWs5gc43Fmgvk37HA5cA 7u8B0KRjBTuHUAqZUc71KCYTY0dlt29J3CRQAFxfUsWcXXDqalhD8LIQhvKTTi+YR+/B CT/S+5H+JMhQGAvVY8jIFRtij9tFI70TiENjHTbUAdj34ACb9K5eBTkt9ERVoMy/WAWM sOv62shNju8FkQptsVsjTTI+/Vz5wuf0Rwj7VrcScuiPIiHj0iToebcVEUdDqsi0CdoI mHTW4U4zN6dVWRwHLIR4Xa+5ROmkk+PP+WfCZk0yAFC3Idn1Cxk6liS0Bk2rzS/HJtCM mOFw== X-Gm-Message-State: APjAAAUrUlok2n/h/VE/8R4n+ykqEr2eku6FKwXOGp4vaEjWmHXraYGt 6dGg4omiNe3KPLVvefcgvvkVSIRX X-Received: by 2002:a1c:f003:: with SMTP id a3mr1584888wmb.41.1579680414195; Wed, 22 Jan 2020 00:06:54 -0800 (PST) Received: from localhost (ip-37-188-245-167.eurotel.cz. [37.188.245.167]) by smtp.gmail.com with ESMTPSA id p15sm2716017wma.40.2020.01.22.00.06.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jan 2020 00:06:52 -0800 (PST) Date: Wed, 22 Jan 2020 09:06:51 +0100 From: Michal Hocko To: Yang Shi Cc: Wei Yang , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] mm: move_pages: fix the return value if there are not-migrated pages Message-ID: <20200122080651.GN29276@dhcp22.suse.cz> References: <1579325203-16405-1-git-send-email-yang.shi@linux.alibaba.com> <20200120130624.GD18451@dhcp22.suse.cz> <20200120131744.GE18451@dhcp22.suse.cz> <20200121014416.GC1567@richard> <20200121084040.GC29276@dhcp22.suse.cz> <27b993f4-cc50-d5a9-1cda-89dd022aea16@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27b993f4-cc50-d5a9-1cda-89dd022aea16@linux.alibaba.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 21-01-20 11:01:30, Yang Shi wrote: > > > On 1/21/20 12:40 AM, Michal Hocko wrote: > > On Tue 21-01-20 09:44:16, Wei Yang wrote: > > > On Mon, Jan 20, 2020 at 02:17:44PM +0100, Michal Hocko wrote: > > > > On Mon 20-01-20 14:06:26, Michal Hocko wrote: > > > > > On Sat 18-01-20 13:26:43, Yang Shi wrote: > > > > > > The do_move_pages_to_node() might return > 0 value, the number of pages > > > > > > that are not migrated, then the value will be returned to userspace > > > > > > directly. But, move_pages() syscall would just return 0 or errno. So, > > > > > > we need reset the return value to 0 for such case as what pre-v4.17 did. > > > > > The patch is wrong. migrate_pages returns the number of pages it > > > > > _hasn't_ migrated or -errno. Yeah that semantic sucks but... > > > > > So err != 0 is always an error. Except err > 0 doesn't really provide > > > > > any useful information to the userspace. I cannot really remember what > > > > > was the actual behavior before my rework because there were some gotchas > > > > > hidden there. > > > > OK, so I've double checked. do_move_page_to_node_array would carry the > > > > error code over to do_pages_move and it would store the status stored > > > > in the pm array. It contains page_to_nid(page) so the resulting code > > > > indeed behaves properly before my change and this is a regression. I > > > Thanks, I see the change. > > > > > > > have a very vague recollection that this has been brought up already. > > > > <...looks in notes...> > > > > Found it! The report is > > > > http://lkml.kernel.org/r/0329efa0984b9b0252ef166abb4498c0795fab36.1535113317.git.jstancek@redhat.com > > > > and my proposed workaround was http://lkml.kernel.org/r/20180829145537.GZ10223@dhcp22.suse.cz > > > Well, the above two links return 404. > > You are right. They are not archived for some reason. Anyway, the patch > > I was proposing back then is below: > > > > commit cfb88c266b645197135cde2905c2bfc82f6d82a9 > > Author: Michal Hocko > > Date: Wed Nov 14 12:19:09 2018 +0100 > > > > mm: fix do_pages_move error reporting > > a49bd4d71637 ("mm, numa: rework do_pages_move") has changed the way how > > we report error to layers above. As the changelog mentioned the semantic > > was quite unclear previously because the return 0 could mean both > > success and failure. > > The above mentioned commit didn't get all the way down to fix this > > completely because it doesn't report pages that we even haven't > > attempted to migrate and therefore we cannot simply say that the > > semantic is: > > - err < 0 - errno > > - err >= 0 number of non-migrated pages. > > Fixes: a49bd4d71637 ("mm, numa: rework do_pages_move") > > Signed-off-by: Michal Hocko > > Thanks, Michal. But, it looks this patch still could return > 0 value (the > total number of non-migrated pages, including not even attempted pages) too, > but the problem we are trying to fix is to make do_pages_move() return <= 0 > value only since the man page of move_pages() doesn't allow return > 0 > value. Yes this patch just lives with the changed semantic and tries to make it sensible. So if some page cannot be migrated then we just stop and return the number of non migrated pages at the tail of the given array. This would make error handling slightly easier because you know that count - ret pages of the array can be skipped if ret >= 0. > And, by looking into the old code (v4.16), I spotted another problem. The > migrate_pages() would store the migration failure error code into > page_to_node->status. So, When do_move_page_to_node_array() returns > 0 > value, the return value would be reset to 0 and the migration error codes > for non-migrated pages would be stored into status to return to userspace. > But, the rework removed this. > > I didn't dig into the intention of the rework, is it expected? I have tried to preserve the original semantic as possible. As explained in the changelog there were quite some discrepancies even before. This new one was not really intentional. We have effectively two options here. Either somebody really depend on the former semantic and we have to fix this or we can relax the semantic as the above patch attempts. I would be more inclined for the second option as nobody has complained about the new semantic except for few ltp tests which do not represent real workload. If you have a real usecase then speak up please. -- Michal Hocko SUSE Labs