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>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Ralph Campbell <rcampbell@nvidia.com>
Subject: Re: [PATCH] mm/gup.c: Refactor check_and_migrate_movable_pages()
Date: Fri, 05 Aug 2022 11:56:58 +1000	[thread overview]
Message-ID: <87v8r75ssf.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <YuuwSoZpRI9kKtLF@nvidia.com>


Jason Gunthorpe <jgg@nvidia.com> writes:

> On Thu, Aug 04, 2022 at 01:22:41PM +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>
>> Cc: "Sierra Guiza, Alejandro (Alex)" <alex.sierra@amd.com>
>> Cc: Chaitanya Kulkarni <kch@nvidia.com>
>> Cc: Dan Williams <dan.j.williams@intel.com>
>> Cc: Felix Kuehling <Felix.Kuehling@amd.com>
>> Cc: Jason Gunthorpe <jgg@nvidia.com>
>> Cc: John Hubbard <jhubbard@nvidia.com>
>> Cc: Logan Gunthorpe <logang@deltatee.com>
>> Cc: Miaohe Lin <linmiaohe@huawei.com>
>> Cc: Muchun Song <songmuchun@bytedance.com>
>> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
>> Cc: Ralph Campbell <rcampbell@nvidia.com>
>>
>> ---
>>
>> Originally posted as "mm/gup.c: Simplify and fix
>> check_and_migrate_movable_pages() return codes"[1].
>>
>> Changes from that version:
>>
>>  - Restore the original isolation failure behaviour and don't fail the
>>    pup. Instead retry indefinitely.
>>  - Unpin all pages on retry or failure rather than just failure.
>>
>> Jason - I dropped your Reviewed-by. I had to remove the changes to make
>> error handling follow convention as we need to always unpin the pages.
>> We also need the list_empty() checks because we may or may not have
>> pages in the list if we found coherent pages. So there isn't much I
>> could see to simplify, but let me know if you spot some.
>
> I don't quite understand this, if the point is to loop on the LRU
> indefinately, why not just code that? Why do we need to go around the
> big loop?

I assume by "big loop" you mean calling
check_and_migrate_movable_pages() again? We have to do that after the
migration anyway. Looping on the LRU indefinitely inside
check_and_migrate_movable_pages() doesn't remove that requirement so I'm
not convinced it would simplify things much.

It could also lead to deadlock because we may already have other pages
isolated from the LRU.

 - Alistair

> Jason


  reply	other threads:[~2022-08-05  2:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04  3:22 [PATCH] mm/gup.c: Refactor check_and_migrate_movable_pages() Alistair Popple
2022-08-04 11:40 ` Jason Gunthorpe
2022-08-05  1:56   ` Alistair Popple [this message]
2022-08-04 23:06 ` John Hubbard

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=87v8r75ssf.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=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=pasha.tatashin@soleen.com \
    --cc=rcampbell@nvidia.com \
    --cc=songmuchun@bytedance.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.