From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2B15C2D0CE for ; Fri, 24 Jan 2020 06:46:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4D2C420709 for ; Fri, 24 Jan 2020 06:46:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D2C420709 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C70D36B02B1; Fri, 24 Jan 2020 01:46:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C21606B02B2; Fri, 24 Jan 2020 01:46:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B38A36B02B3; Fri, 24 Jan 2020 01:46:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id 9F34F6B02B1 for ; Fri, 24 Jan 2020 01:46:53 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 58762180AD806 for ; Fri, 24 Jan 2020 06:46:53 +0000 (UTC) X-FDA: 76411595106.28.twig08_3c12a893e4435 X-HE-Tag: twig08_3c12a893e4435 X-Filterd-Recvd-Size: 6212 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jan 2020 06:46:52 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id s144so3397183wme.1 for ; Thu, 23 Jan 2020 22:46:52 -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=ceFjGGiWoFMAA9UT7Zn787IQlb7e7FJtvY2pMaDdPIg=; b=Qdx7SpW0EsgB1Y4Rs1/NrR/eao3AKJxeIVVo3F6AhY8dm3evCQlLekt94aU0Hs39gI C+MawsZ1vYAfFbAA/4/GB/Nfkt0vtjIVvbbkC0feDogCVEcDLAOHs0dxEtDrJwFtuf+E 9dz74sGibUNnTc49UXIoKhpwtvDK0B2gdwTcicLgY8Ma58lv+6HpMzFLKC2FfnflgHIz Zh084sT2QcV1wtC2+d3lWfuQhDapdjpaQk4IkGc6xsRDmogwUCd1h8mfpF7DCimqhDU/ W8Sy+SJbleeITbqT0pUUFo4pNjiXAP+tTgZDRfE3+etL8CM0SZpQf0HjW+UForAMxaDT D0/g== X-Gm-Message-State: APjAAAWrkwJ/naFpPxcDbzOzgOgkwNNqb4I02+ilgi/9Dx1uBVY8eedx YD57ht6Efr+OeubuT85HVhw= X-Google-Smtp-Source: APXvYqwVDEdRt5Olnj1NsGVliK0l7NWMm0Od52XXHYIaFzv034E6xvGh2WxWdUyCXdlSGFI7kDuovQ== X-Received: by 2002:a1c:7c11:: with SMTP id x17mr1871368wmc.168.1579848411533; Thu, 23 Jan 2020 22:46:51 -0800 (PST) Received: from localhost (ip-37-188-162-110.eurotel.cz. [37.188.162.110]) by smtp.gmail.com with ESMTPSA id c195sm6257033wmd.45.2020.01.23.22.46.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jan 2020 22:46:50 -0800 (PST) Date: Fri, 24 Jan 2020 07:46:49 +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: <20200124064649.GM29276@dhcp22.suse.cz> References: <1579736331-85494-1-git-send-email-yang.shi@linux.alibaba.com> <20200123032736.GA22196@richard> <20200123085526.GH29276@dhcp22.suse.cz> <20200123225647.GB29851@richard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200123225647.GB29851@richard> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri 24-01-20 06:56:47, Wei Yang wrote: > On Thu, Jan 23, 2020 at 09:55:26AM +0100, Michal Hocko wrote: > >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. > > > > So for a user, the best practice is to initialize the status array to -1 and > check each status to see whether the page is migrated successfully? Yes IMO. Just consider -errno return value. You have no way to find out which pages have been migrated until we reached that error. The possitive return value would fall into the same case. > Then do we need to return the number of non-migrated page? What benefit could > user get from the number. How about just return an error code to indicate the > failure? I may miss some point, would you mind giving me a hint? This is certainly possible. We can return -EAGAIN if some pages couldn't be migrated because they are pinned. But please read my previous email to the very end for arguments why this might cause more problems than it actually solves. > >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