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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87F59E92FFD for ; Sat, 7 Oct 2023 07:29:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343706AbjJGH3m (ORCPT ); Sat, 7 Oct 2023 03:29:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343632AbjJGH3k (ORCPT ); Sat, 7 Oct 2023 03:29:40 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75A6FDF for ; Sat, 7 Oct 2023 00:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696663777; x=1728199777; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=KKsNX1B4ephXy3wePWdgK65UEebN0b8CYmREFVzaYus=; b=XkxLB8kcPupSoCwHMN1w4I/J3oD2UHlVluX/dZF/plqno785ojFrIrDA FLnddfmkpZAq4ddaGaoKz6Kf+DR8AHOX7n28KsQw7wDlwg76qblQrySgh ZS9b9I4p9kG/RJcE2g5idIyNWFeeCYqct5TfNBCgVEAW57lfqUna9a1SW vqsyWaVP9hkWKMY7juIifDBOi3J7zlpFAS2PGw4i4nHnr1F+sOVQ8QFAq ZvN77mH9SYJ8d43EmQOYVxovsgQshR/cA3DbQMDo2G24l71JWR21TPg8k reJVCcukKtnX0m2DW4merjswrr0zSjLIGwa5JdSce943VjkkPHk40wIR/ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10855"; a="382768536" X-IronPort-AV: E=Sophos;i="6.03,205,1694761200"; d="scan'208";a="382768536" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2023 00:29:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10855"; a="868608902" X-IronPort-AV: E=Sophos;i="6.03,205,1694761200"; d="scan'208";a="868608902" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2023 00:29:32 -0700 From: "Huang, Ying" To: Hugh Dickins Cc: Andrew Morton , Andi Kleen , Christoph Lameter , Matthew Wilcox , Mike Kravetz , David Hildenbrand , Suren Baghdasaryan , Yang Shi , Sidhartha Kumar , Vishal Moola , Kefeng Wang , Greg Kroah-Hartman , Tejun Heo , Mel Gorman , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 03/12] mempolicy: fix migrate_pages(2) syscall return nr_failed References: <9a6b0b9-3bb-dbef-8adf-efab4397b8d@google.com> Date: Sat, 07 Oct 2023 15:27:23 +0800 In-Reply-To: <9a6b0b9-3bb-dbef-8adf-efab4397b8d@google.com> (Hugh Dickins's message of "Tue, 3 Oct 2023 02:17:43 -0700 (PDT)") Message-ID: <87o7halwo4.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hugh Dickins writes: > "man 2 migrate_pages" says "On success migrate_pages() returns the number > of pages that could not be moved". Although 5.3 and 5.4 commits fixed > mbind(MPOL_MF_STRICT|MPOL_MF_MOVE*) to fail with EIO when not all pages > could be moved (because some could not be isolated for migration), > migrate_pages(2) was left still reporting only those pages failing at the > migration stage, forgetting those failing at the earlier isolation stage. > > Fix that by accumulating a long nr_failed count in struct queue_pages, > returned by queue_pages_range() when it's not returning an error, for > adding on to the nr_failed count from migrate_pages() in mm/migrate.c. > A count of pages? It's more a count of folios, but changing it to pages > would entail more work (also in mm/migrate.c): does not seem justified. > > queue_pages_range() itself should only return -EIO in the "strictly > unmovable" case (STRICT without any MOVEs): in that case it's best to > break out as soon as nr_failed gets set; but otherwise it should continue > to isolate pages for MOVing even when nr_failed - as the mbind(2) manpage > promises. > > There's a case when nr_failed should be incremented when it was missed: > queue_folios_pte_range() and queue_folios_hugetlb() count the transient > migration entries, like queue_folios_pmd() already did. And there's a > case when nr_failed should not be incremented when it would have been: > in meeting later PTEs of the same large folio, which can only be isolated > once: fixed by recording the current large folio in struct queue_pages. > > Clean up the affected functions, fixing or updating many comments. Bool > migrate_folio_add(), without -EIO: true if adding, or if skipping shared > (but its arguable folio_estimated_sharers() heuristic left unchanged). > Use MPOL_MF_WRLOCK flag to queue_pages_range(), instead of bool lock_vma. > Use explicit STRICT|MOVE* flags where queue_pages_test_walk() checks for > skipping, instead of hiding them behind MPOL_MF_VALID. > > Signed-off-by: Hugh Dickins > Reviewed-by: Matthew Wilcox (Oracle) Thanks! Feel free to add Reviewed-by: "Huang, Ying" -- Best Regards, Huang, Ying