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 >>>>>> <[email protected]> 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
