All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jason Gunthorpe <jgg@nvidia.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-rdma@vger.kernel.org, linux-mm@kvack.org,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Leon Romanovsky <leon@kernel.org>,
	Artemy Kovalyov <artemyko@nvidia.com>,
	Michael Guralnik <michaelgur@nvidia.com>,
	Alistair Popple <apopple@nvidia.com>,
	Pak Markthub <pmarkthub@nvidia.com>
Subject: Re: [RFC] RDMA/umem: pin_user_pages*() can temporarily fail due to migration glitches
Date: Tue, 30 Apr 2024 22:10:43 -0700	[thread overview]
Message-ID: <ZjHO04Rb75TIlmkA@infradead.org> (raw)
In-Reply-To: <20240501003117.257735-1-jhubbard@nvidia.com>

> +		pinned = -ENOMEM;
> +		int attempts = 0;
> +		/*
> +		 * pin_user_pages_fast() can return -EAGAIN, due to falling back
> +		 * to gup-slow and then failing to migrate pages out of
> +		 * ZONE_MOVABLE due to a transient elevated page refcount.
> +		 *
> +		 * One retry is enough to avoid this problem, so far, but let's
> +		 * use a slightly higher retry count just in case even larger
> +		 * systems have a longer-lasting transient refcount problem.
> +		 *
> +		 */
> +		static const int MAX_ATTEMPTS = 3;
> +
> +		while (pinned == -EAGAIN && attempts < MAX_ATTEMPTS) {
> +			pinned = pin_user_pages_fast(cur_base,
> +						     min_t(unsigned long,
> +							npages, PAGE_SIZE /
> +							sizeof(struct page *)),
> +						     gup_flags, page_list);
>  			ret = pinned;
> -			goto umem_release;
> +			attempts++;
> +
> +			if (pinned == -EAGAIN)
> +				continue;
>  		}
> +		if (pinned < 0)
> +			goto umem_release;

This doesn't make sense.  IFF a blind retry is all that is needed it
should be done in the core functionality.  I fear it's not that easy,
though.


  reply	other threads:[~2024-05-01  5:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-01  0:31 [RFC] RDMA/umem: pin_user_pages*() can temporarily fail due to migration glitches John Hubbard
2024-05-01  5:10 ` Christoph Hellwig [this message]
2024-05-01 12:10   ` Jason Gunthorpe
2024-05-01 17:32     ` John Hubbard
2024-05-02  1:05     ` Alistair Popple
2024-05-02  6:49       ` John Hubbard
2024-05-02  6:56       ` David Hildenbrand
2024-05-02 18:10         ` John Hubbard
2024-05-02 18:34           ` Jason Gunthorpe
2024-05-02 18:44             ` Matthew Wilcox
2024-05-10  7:54           ` David Hildenbrand
2024-05-11  0:32             ` Kasireddy, Vivek

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=ZjHO04Rb75TIlmkA@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=artemyko@nvidia.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michaelgur@nvidia.com \
    --cc=mike.marciniszyn@intel.com \
    --cc=pmarkthub@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.