Re: [PATCH] mm/hmm: Fix a hmm_range_fault() livelock / starvation problem

[John Hubbard <jhubbard@nvidia.com>]

On 2/2/26 1:13 AM, Thomas Hellström wrote:
> On Sat, 2026-01-31 at 13:42 -0800, John Hubbard wrote:
>> On 1/31/26 11:00 AM, Matthew Brost wrote:
>>> On Sat, Jan 31, 2026 at 01:57:21PM +0100, Thomas Hellström wrote:
>>>> On Fri, 2026-01-30 at 19:01 -0800, John Hubbard wrote:
>>>>> On 1/30/26 10:00 AM, Andrew Morton wrote:
>>>>>> On Fri, 30 Jan 2026 15:45:29 +0100 Thomas Hellström
>>>>>> <thomas.hellstrom@linux.intel.com> wrote:
>>>>> ...
>>
>>>
>>>> I'm also not sure a folio refcount should block migration after
>>>> the
>>>> introduction of pinned (like in pin_user_pages) pages. Rather
>>>> perhaps a
>>>> folio pin-count should block migration and in that case
>>>> do_swap_page()
>>>> can definitely do a sleeping folio lock and the problem is gone.
>>
>> A problem for that specific point is that pincount and refcount both
>> mean, "the page is pinned" (which in turn literally means "not
>> allowed
>> to migrate/move").
> 
> Yeah this is what I actually want to challenge since this is what
> blocks us from doing a clean robust solution here. From brief reading
> of the docs around the pin-count implementation, I understand it as "If
> you want to access the struct page metadata, get a refcount, If you
> want to access the actual memory of a page, take a pin-count"
> 
> I guess that might still not be true for all old instances in the
> kernel using get_user_pages() instead of pin_user_pages() for things
> like DMA, but perhaps we can set that in stone and document it at least
> for device-private pages for now which would be sufficient for the
> do_swap_pages() refcount not to block migration.
> 

It's an interesting direction to go...

> 
>>
>> (In fact, pincount is implemented in terms of refcount, in most
>> configurations still.)
> 
> Yes but that's only a space optimization never intended to conflict,
> right? Meaning a pin-count will imply a refcount but a refcount will
> never imply a pin-count?
> 
Unfortunately, they are more tightly linked than that today, at least until
someday when specialized folios are everywhere (at which point pincount
gets its own field).

Until then, it's not just a "space optimization", it's "overload refcount
to also do pincounting". And "let core mm continue to treat refcounts as
meaning that the page is pinned".


thanks,
-- 
John Hubbard