Re: [PATCH] mm/gup: Drain batched mlock folio processing before attempting migration

[John Hubbard <jhubbard@nvidia.com>]

On 9/9/25 4:50 AM, David Hildenbrand wrote:
> On 09.09.25 13:39, Will Deacon wrote:
>> On Fri, Aug 29, 2025 at 08:46:52AM -0700, Hugh Dickins wrote:
>>> On Fri, 29 Aug 2025, Will Deacon wrote:
>>>> On Thu, Aug 28, 2025 at 01:47:14AM -0700, Hugh Dickins wrote:
...
> Migration code itself will retry multiple times, which usually takes 
> care of most races.
> 
> Not all of course.
> 
> Now, I recall John was working on that at some point (I recall an RFC 
> patch, but I might be daydreaming), and I recall discussions at LSF/MM 

Yes. I was trying to improve the gup scenario of "try to long-term pin
pages that are currently in ZONE_MOVABLE, and must therefore be migrated
before pinning them". The problem is that the current code just retries
in a loop, when what we really want is for it to go to sleep and wait
for the pages to become migratable.

Anyway, I had trouble finding something to wait *on*. David here at
the last LSF/MM suggested waiting on a page group, but I only partially
understand the approach--and what really happened is that I am
"temporarily" (for a few years) consumed by this entertaining new
Nova (Rust for Linux) project.

And so I've failed to make any progress there this year.


> around improving handling when we are mixing a flood of short-therm gup 
> with a single long-term gup that wants to migrate these (short-term 
> pinned) pages.
> 
> Essentially, we would have to temporarily prevent new short-term GUP 
> pins in order to make the long-term GUP-pin succeed in migrating the folio.
> 

thanks,
-- 
John Hubbard