linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@linux.intel.com>, Christoph Lameter <cl@linux.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	David Hildenbrand <david@redhat.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Yang Shi <shy828301@gmail.com>,
	Sidhartha Kumar <sidhartha.kumar@oracle.com>,
	Vishal Moola <vishal.moola@gmail.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tejun Heo <tj@kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Michal Hocko <mhocko@suse.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 03/12] mempolicy: fix migrate_pages(2) syscall return nr_failed
Date: Mon, 25 Sep 2023 23:22:24 +0100	[thread overview]
Message-ID: <ZRIIIFm5IMnkGh3T@casper.infradead.org> (raw)
In-Reply-To: <ddad2cee-cbad-7b5d-935a-59f961b7c3a@google.com>

On Mon, Sep 25, 2023 at 01:24:02AM -0700, Hugh Dickins wrote:
> "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.

I certainly see what you're saying.  If a folio is only partially mapped
(in an extreme case, the VMA is PAGE_SIZE and maps one page of a 512-page
folio), then setting nr_failed to folio_nr_pages() is misleading at best.

> +static void queue_folios_pmd(pmd_t *pmd, spinlock_t *ptl, unsigned long addr,
>  				unsigned long end, struct mm_walk *walk)
> -	__releases(ptl)
>  {
> -	int ret = 0;
>  	struct folio *folio;
>  	struct queue_pages *qp = walk->private;
> -	unsigned long flags;
>  
>  	if (unlikely(is_pmd_migration_entry(*pmd))) {
> -		ret = -EIO;
> -		goto unlock;
> +		qp->nr_failed++;
> +		return;
>  	}
>  	folio = pfn_folio(pmd_pfn(*pmd));
>  	if (is_huge_zero_page(&folio->page)) {
>  		walk->action = ACTION_CONTINUE;
> -		goto unlock;
> +		return;
>  	}
>  	if (!queue_folio_required(folio, qp))
> -		goto unlock;
> -
> -	flags = qp->flags;
> -	/* go to folio migration */
> -	if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) {
> -		if (!vma_migratable(walk->vma) ||
> -		    migrate_folio_add(folio, qp->pagelist, flags)) {
> -			ret = 1;
> -			goto unlock;
> -		}
> -	} else
> -		ret = -EIO;
> -unlock:
> -	spin_unlock(ptl);
> -	return ret;
> +		return;
> +	if (!(qp->flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) ||
> +	    !vma_migratable(walk->vma) ||
> +	    !migrate_folio_add(folio, qp->pagelist, qp->flags))
> +		qp->nr_failed++;

However, I think here, we would do well to increment by HPAGE_PMD_NR.
Or whatever equivalent is flavour of the week.

Bravo to the other changes.

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

  reply	other threads:[~2023-09-25 22:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-25  8:17 [PATCH 00/12] mempolicy: cleanups leading to NUMA mpol without vma Hugh Dickins
2023-09-25  8:21 ` [PATCH 01/12] hugetlbfs: drop shared NUMA mempolicy pretence Hugh Dickins
2023-09-25 22:09   ` Matthew Wilcox
2023-09-25 22:46   ` Andi Kleen
2023-09-26 22:26     ` Hugh Dickins
2023-09-25  8:22 ` [PATCH 02/12] kernfs: drop shared NUMA mempolicy hooks Hugh Dickins
2023-09-25 22:10   ` Matthew Wilcox
2023-09-25  8:24 ` [PATCH 03/12] mempolicy: fix migrate_pages(2) syscall return nr_failed Hugh Dickins
2023-09-25 22:22   ` Matthew Wilcox [this message]
2023-09-26 20:47     ` Hugh Dickins
2023-09-27  8:02   ` Huang, Ying
2023-09-30  4:20     ` Hugh Dickins
2023-09-25  8:25 ` [PATCH 04/12] mempolicy trivia: delete those ancient pr_debug()s Hugh Dickins
2023-09-25 22:23   ` Matthew Wilcox
2023-09-25  8:26 ` [PATCH 05/12] mempolicy trivia: slightly more consistent naming Hugh Dickins
2023-09-25 22:28   ` Matthew Wilcox
2023-09-25  8:28 ` [PATCH 06/12] mempolicy trivia: use pgoff_t in shared mempolicy tree Hugh Dickins
2023-09-25 22:31   ` Matthew Wilcox
2023-09-25 22:38     ` Matthew Wilcox
2023-09-26 21:19     ` Hugh Dickins
2023-09-25  8:29 ` [PATCH 07/12] mempolicy: mpol_shared_policy_init() without pseudo-vma Hugh Dickins
2023-09-25 22:50   ` Matthew Wilcox
2023-09-26 21:36     ` Hugh Dickins
2023-09-25  8:30 ` [PATCH 08/12] mempolicy: remove confusing MPOL_MF_LAZY dead code Hugh Dickins
2023-09-25 22:52   ` Matthew Wilcox
2023-09-25  8:32 ` [PATCH 09/12] mm: add page_rmappable_folio() wrapper Hugh Dickins
2023-09-25 22:58   ` Matthew Wilcox
2023-09-26 21:58     ` Hugh Dickins
2023-09-25  8:33 ` [PATCH 10/12] mempolicy: alloc_pages_mpol() for NUMA policy without vma Hugh Dickins
2023-09-25  8:35 ` [PATCH 11/12] mempolicy: mmap_lock is not needed while migrating folios Hugh Dickins
2023-09-25  8:36 ` [PATCH 12/12] mempolicy: migration attempt to match interleave nodes Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZRIIIFm5IMnkGh3T@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=shy828301@gmail.com \
    --cc=sidhartha.kumar@oracle.com \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=vishal.moola@gmail.com \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).