All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, "Sierra Guiza,
	Alejandro (Alex)" <alex.sierra@amd.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Felix Kuehling <Felix.Kuehling@amd.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Logan Gunthorpe <logang@deltatee.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v4 2/2] mm/gup.c: Refactor check_and_migrate_movable_pages()
Date: Tue, 16 Aug 2022 15:29:20 +1000	[thread overview]
Message-ID: <87edxgvixy.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <YvpxOyrDBUHagpC6@nvidia.com>


Jason Gunthorpe <jgg@nvidia.com> writes:

> On Fri, Aug 12, 2022 at 12:13:09PM +1000, Alistair Popple wrote:
>> When pinning pages with FOLL_LONGTERM check_and_migrate_movable_pages()
>> is called to migrate pages out of zones which should not contain any
>> longterm pinned pages.
>>
>> When migration succeeds all pages will have been unpinned so pinning
>> needs to be retried. Migration can also fail, in which case the pages
>> will also have been unpinned but the operation should not be retried. If
>> all pages are in the correct zone nothing will be unpinned and no retry
>> is required.
>>
>> The logic in check_and_migrate_movable_pages() tracks unnecessary state
>> and the return codes for each case are difficult to follow. Refactor the
>> code to clean this up. No behaviour change is intended.
>>
>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>>
>> ---
>
> This seems like the cleanest version yet!

Thanks, the feedback from John and yourself has been very useful!

>> +static long check_and_migrate_movable_pages(unsigned long nr_pages,
>> +					    struct page **pages)
>> +{
>> +	int ret;
>> +	unsigned long collected;
>> +	LIST_HEAD(movable_page_list);
>> +
>> +	collected = collect_longterm_unpinnable_pages(&movable_page_list, nr_pages, pages);
>> +	if (!collected)
>> +		return 0;
>> +
>> +	ret = migrate_longterm_unpinnable_pages(&movable_page_list, nr_pages, pages);
>> +	if (!ret)
>> +		return -EAGAIN;
>> +	else
>> +		return ret;
>
> I would drop the else path and just return zero

Unless I've misunderstood you I don't think that's correct though.
check_and_migrate_movable_pages() needs to return one of 3 conditions:

 - 0: All pages are in the correct zone and are still pinned (ie. "success").
 - -EAGAIN: Some pages were migrated, all pages need re-pinning.
 - errno: Migration failed, pins were dropped and PUP should fail.

John's suggested comment update spells this out more clearly.

> Arguably migrate_longterm_unpinnable_pages() should do the same?

migrate_longterm_unpinnable_pages() returns 0 for success, errno for
some kind of "permanent" failure that needs propagating.

>> @@ -2051,10 +2079,10 @@ static long __gup_longterm_locked(struct mm_struct *mm,
>>  			break;
>>
>>  		rc = check_and_migrate_movable_pages(rc, pages);
>> -	} while (!rc);
>> +	} while (rc == -EAGAIN);
>
> Since the only reader only cares about errno or not errno..

See above. Errors other than -EAGAIN should not be retried.

> But no biggie either way

So will leave this as for now at least.

> Thanks,
> Jason


  reply	other threads:[~2022-08-16  5:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12  2:13 [PATCH v4 1/2] mm/gup.c: Don't pass gup_flags to check_and_migrate_movable_pages() Alistair Popple
2022-08-12  2:13 ` [PATCH v4 2/2] mm/gup.c: Refactor check_and_migrate_movable_pages() Alistair Popple
2022-08-12  7:05   ` John Hubbard
2022-08-15 16:15   ` Jason Gunthorpe
2022-08-16  5:29     ` Alistair Popple [this message]
2022-08-16 11:29       ` Jason Gunthorpe
2022-08-17  2:01         ` Alistair Popple
2022-08-17 12:09           ` Jason Gunthorpe
2022-08-17 20:35             ` John Hubbard
2022-08-17 22:50               ` Jason Gunthorpe
2022-08-17 23:05                 ` John Hubbard
2022-08-17 23:24                 ` Alistair Popple
2022-08-17 23:40                   ` Jason Gunthorpe
2022-08-12 12:57 ` [PATCH v4 1/2] mm/gup.c: Don't pass gup_flags to check_and_migrate_movable_pages() Matthew Wilcox
2022-08-12 18:02   ` John Hubbard
2022-08-12 18:11     ` Matthew Wilcox
2022-08-15  5:52       ` Alistair Popple

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=87edxgvixy.fsf@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.sierra@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=kch@nvidia.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=rcampbell@nvidia.com \
    --cc=songmuchun@bytedance.com \
    --cc=willy@infradead.org \
    /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.