Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp421995ybl; Thu, 23 Jan 2020 00:57:37 -0800 (PST) X-Google-Smtp-Source: APXvYqz40K5ZmG1DrD/fviZ4Xtn4IF7NcW59heaq12pKJ84n8VkKV9AtdOEw7It+mdAUNoG2Ydwj X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr10239173otr.82.1579769857745; Thu, 23 Jan 2020 00:57:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579769857; cv=none; d=google.com; s=arc-20160816; b=DX1qklcBDSyrdZJDoIG8hDHe+eHEL8Vv+VWvD2cGlUMpLk0XilUEQhwoVwXUL64vks enTu6M4hFsRoW5Bu/VwwJOu5KSfD2FJqwSPBLG59cXqXTM5WF5gfKW3V29FTiwI/OCLv Q/+YRmPIcgWOrI04VE+r698QhGR8PWZ3+fGwmwKjHatREgsiYXOLWeLvIP2aAdkqO9H+ MzPNLE6uYcuS+h2I9gdJoTRdlbhXDVjy4q4OyhZL0HrzctzR70bqI8WJSh/bU5Y8Z4Hy RDdodu0XuF0uJFcAy2IjRQdzeFiD+A4Nj0tLR8yveRg35a8dV2q3MGLiAm2dRo4AJScy EmbA== 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=QN0GytJlQ8IoR8mCnHpKkK8Cwd+3Z4QrENywxxSV18c=; b=wyUUot/vzejKDMVTFqyDQnRnD1W6vbdrmr73ADnLfKGdUcTK0OWG3VMG3QqZYcbTo1 zp9DR7NxHaYIX4gV6r8qz74fTWQmlvb7hfMawyin+G6DJYum67jisRQQUVdTen/mpCMs 8TPR/xBxvevqLJbyC7HSF17TY5FtRfTYF+9i35b2riz74QfMsuLYQ0LDhIVEkETq/bDY my7uiJvjBFD3qx6h51M8Td/TJsmfTehZzdS5JePxbV+IuLoiDKHQAj08yfiNNV3pbnh9 0rMcaEjdn8A6bFddBYw/hANIA6BDAs9Goxrodv2wP/v/hzq3KajA4OmfD9L13bEzM9lj WYeQ== 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 t82si559796oif.45.2020.01.23.00.57.25; Thu, 23 Jan 2020 00:57:37 -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 S1727307AbgAWIza (ORCPT + 99 others); Thu, 23 Jan 2020 03:55:30 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:46022 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725785AbgAWIza (ORCPT ); Thu, 23 Jan 2020 03:55:30 -0500 Received: by mail-wr1-f66.google.com with SMTP id j42so2090715wrj.12; Thu, 23 Jan 2020 00:55:28 -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=QN0GytJlQ8IoR8mCnHpKkK8Cwd+3Z4QrENywxxSV18c=; b=l+xpVWnEjOFkUjd5ufVUmmO3pxr/q5FSCe5xcJG6Pn0ugmSOrgrRKjyiqEB5rt7sab lZxtzjbHw4nteRmF86/EWiJUIEoPAWbyIj5rtd7qf4am4X8OLxcWTb3JLOMmHBGvSWMq psirjH41GsGDa+iLTwizJtQl/c0FPSxvVyR7QqHmGxjcOcfRPeG8Q8TIVwsgkcVVYC7n XO/2WxBNmIuVNCigQHmrAhZtpHpG9r1HxtOgNXlpVLfL+xQmjYqp70ZeFo2td/6VgdxN wDJ2Wil1HdyLWuHr5nRzliDyc/H1ddrawRtS5dW56mNtgyadh2gIh2REKdnOx2/9erVR kzNQ== X-Gm-Message-State: APjAAAWrXfOmxR670rUUj7c8OlgzbDFu9KBSK6P+2eiuy/LsUhhvppYr gvnODqyqsEVZY5wi9Ucrnl8= X-Received: by 2002:adf:dfc1:: with SMTP id q1mr16374200wrn.155.1579769727653; Thu, 23 Jan 2020 00:55:27 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id f12sm1821295wmf.28.2020.01.23.00.55.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jan 2020 00:55:26 -0800 (PST) Date: Thu, 23 Jan 2020 09:55:26 +0100 From: Michal Hocko To: Wei Yang Cc: Yang Shi , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [v2 PATCH] mm: move_pages: report the number of non-attempted pages Message-ID: <20200123085526.GH29276@dhcp22.suse.cz> References: <1579736331-85494-1-git-send-email-yang.shi@linux.alibaba.com> <20200123032736.GA22196@richard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200123032736.GA22196@richard> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 23-01-20 11:27:36, Wei Yang wrote: > On Thu, Jan 23, 2020 at 07:38:51AM +0800, Yang Shi wrote: > >Since commit a49bd4d71637 ("mm, numa: rework do_pages_move"), > >the semantic of move_pages() was changed to return the number of > >non-migrated pages (failed to migration) and the call would be aborted > >immediately if migrate_pages() returns positive value. But it didn't > >report the number of pages that we even haven't attempted to migrate. > >So, fix it by including non-attempted pages in the return value. > > > > First, we want to change the semantic of move_pages(2). The return value > indicates the number of pages we didn't managed to migrate? > > Second, the return value from migrate_pages() doesn't mean the number of pages > we failed to migrate. For example, one -ENOMEM is returned on the first page, > migrate_pages() would return 1. But actually, no page successfully migrated. ENOMEM is considered a permanent failure and as such it is returned by migrate pages (see goto out). > Third, even the migrate_pages() return the exact non-migrate page, we are not > sure those non-migrated pages are at the tail of the list. Because in the last > case in migrate_pages(), it just remove the page from list. It could be a page > in the middle of the list. Then, in userspace, how the return value be > leveraged to determine the valid status? Any page in the list could be the > victim. Yes, I was wrong when stating that the caller would know better which status to check. I misremembered the original patch as it was quite some time ago. While storing the error code would be possible after some massaging of migrate_pages is this really something we deeply care about. The caller can achieve the same by initializing the status array to a non-node number - e.g. -1 - and check based on that. This system call has quite a complex semantic and I am not 100% sure what is the right thing to do here. Maybe we do want to continue and try to migrate as much as possible on non-fatal migration failures and accumulate the number of failed pages while doing so. The main problem is that we can have an academic discussion but the primary question is what do actual users want. A lack of real bug reports suggests that nobody has actually noticed this. So I would rather keep returning the correct number of non-migrated pages. Why? Because new users could have started depending on it. It is not all that unlikely that the current implementation would just work for them because they are migrating a set of pages on to the same node so the batch would be a single list throughout the whole given page set. -- Michal Hocko SUSE Labs